Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
andrewj

Eureka 0.81 Released

Recommended Posts

Eureka is a DOOM editor for Linux, and I have just released the 0.81 version.

You can get it here: http://eureka-editor.sourceforge.net/

This version has proper Unix-style installation, that was the main focus of this release. Other features include a command to build nodes (via glBSP), resizable texture browser, better sector handling (SPACE key can correct a broken sector), and better code to detect iwads, plus various other minor fixes and enhancements.

This is available as source only, and requires FLTK 1.3.0+ and a C++ build environment to compile. See the included README.txt and INSTALL.txt documents.

Share this post


Link to post

Coming from Doom Builder, parts of this feel really primitive. At the same time, I'm loving the panels. That's such an efficient way of dealing with editing that I'm surprised no other editor (to my knowledge) uses them, opting for windows instead.

I have a lot of feedback about this, so much actually that I'm not sure how to organize it, or even that you want to hear it (a lot of it is personal preferences). The editor compiled on Mint 13 x64, although I needed to grab a few packages not mentioned in the readme, and everything worked fine when I made a test map.

Share this post


Link to post

Yeah I'm happy to hear lots of detailed feedback, as long as your happy if I don't reply to every point made.

I don't think this editor will ever be as easy to use a Doom Builder, but I'm fairly satisfied with the fundamental workflow, and of course there is plenty of room for improvement in most aspects of the program (e.g. File/Open is very clunky, I plan to have a proper scrolling list of drawn maps to click on).

Documentation is sorely lacking too, something I will definitely work on as I continue to develop it (and there is plenty of Yadex documentation which I can use for inspiration).

Share this post


Link to post

Yeah,Yeah,Yeah,Yeah,Yeah, finally a good editor for Linux!
Thanks a lot and kepp the good work coming!

On (x)ubuntu 12.04 I had to install

libxft-dev
libxinerama-dev
libjpeg-dev

in addition to your given requirements. after that it ran like a breeze.

Share this post


Link to post

Yeah, those are the same packages I had to install on Mint.

As for my feedback, turns out it's not as long as I thought it'd be. I'll keep the important stuff at the top:

High priority

  • Clicking on a texture in the texture browser only sets the texture for the first sidedef, even if the cursor was placed in one of the fields for the second sidedef.
  • Likewise, clicking on a flat only sets the floor texture, regardless of which field the cursor had been in.
  • The editor has to be closed after building nodes. I'm not sure if there's a technical reason for that, but it really interrupts your workflow if you test your stuff often.
  • Like you already said, the GUI file open dialog could use some work. Particularly selecting the iwad and port to use.
Usability
  • I really think you should consider ditching the DEU-style insert key to insert vertices/sectors/things. You're already using the mouse for these, so the most logical thing to use is one of the mouse buttons. I think you could do this without losing any existing functionality, by making clicks context sensitive. If you're hovering over something, select it, otherwise insert a new one. (This is particularly for vertices and things, can't say I've ever used the sector insert option.)
  • Adding onto that context-sensitivity thing, I think you could get away with merging vertex and line modes into a single mode. Right now I draw my lines in vertex mode and only going into line mode to do everything else. It doesn't seem like there's any real need for two separate modes. (Doom Builder is similar in this regard, since you can draw lines, make sectors, and insert vertices in both sectors and lines mode. Always seemed redundant to me.)
  • I think multi-select mode should be default, rather than having to hold ctrl. Since it's so easy to deselect in this editor (although my click to insert suggestion might complicate that), I think it would improve workflow. More often than not I find myself selecting multiple lines/things and setting their properties at once.
  • I think the snap size for insert vertices should be a bit larger. Right now it's hard to get them on an angled line, even at the smaller grid sizes (16x16, 8x8 - smallest I commonly work with).
  • Please add an option to disable automatic texture alignment.
Interface
  • I'm really not digging the grid in this. I prefer to have solid grid lines, like simple mode, but with a special color for the 64x64 flat grid when using other sizes. User-defined special grids would be cool (for example, if you were working on a 1024 map, you could set up a 1024x1024 grid and have that, your normal grid, and the 64x64 flat grid on at the same time.)
  • I'd like to be able to customize line and grid colors.
  • Being able to see line lengths while drawing would be nice.
  • The upper and lower sidedefs are backwards to what I'm used to. Not that big of deal, but they should probably be labeled.
  • Clicking on a texture in linedef mode or a flat in sector mode should open the browser panel if its not already open, and set that texture/flat as the one to be replaced.
  • Being able to change the size of the texture/flat previews in the browser would be nice.
  • The thing editing panel should have a radial layout for setting the thing's angle. (DB uses radio buttons in a circle.)
Keys/controls
  • Having fully customizable controls would make some of the following redundant.
  • I'd like to see flipping linedefs moved to f (free placement could be made F instead), it's such an intuitive key.
  • 3D preview mode should have an option to use a standard WASD + mouse movement scheme. Would require moving w and s functionality to other keys, but would improve workflow in 3D mode dramatically. I suggest stealing DB's g for walk mode (it calls it toggle gravity), maybe p for sprites?
  • 3D preview should just grab the mouse, to make moving around easier, rather than having to hold down right click. Correct me if I'm wrong, but you can't actually do any editing while in 3D mode, so losing the ability to move over to the panels isn't a big deal, and 3D mode can be toggled off to use menus and such.
  • Walk mode should be a toggle, essentially allowing you to move around your map as you would in-game.
  • I keep hitting esc to exit out of 3D preview mode and get the dialog to exit the editor instead. Maybe make esc context sensitive, closing whatever is currently open? (I honestly can't remember the last time I used esc to exit a program directly. In games it usually opens the menu, it most programs I use it doesn't do anything.)
Hopefully I'm not forgetting anything. Those are my complaints/suggestions, but here are the things I'm really liking:
  • Panels! I already mentioned these, but once there's more functionality for selecting what you want to replace, these are going to make editing so much faster. They remind me of the inspectors Romero mentioned when he was describing DoomEd.
  • c to quick copy properties from the selection to whatever you're hovering over. This functionality is completely missing in DB2 by default, which is ridiculous since it speeds up workflow so much, and even with the plugin it's not as easy as Eureka's method.
  • A 3D preview that actually gives a good idea of how your lighting will look in-game. If you get support showing sector effects (as an option, I could see them getting really annoying), this will be perfect.

Share this post


Link to post

The way I test GUI programs is: throw mouse out the window (ok just unplug it or whatever) and then see what breaks. Some programs have keyboard shortcuts for a few things, but then they forget other things and those are hardcoded somehow. If you think this is unrealistic, look at DEU 5.21 (you can operate it entirely without mouse). Unfortunately their mistake was hardcoded keyboard controls, so you'd have to recompile the source to change those bindings.

My other thought is: check the program is usable at any resolution. Some GUI stuff assumes huge screen size (an old X11 program I used was like that, guess they assumed everyone had big Sparcstation display) and you're SOL if your video card or monitor doesn't sync that high (in my case I got around it with FVWM scrolling between desktops to access the parts that were off-screen, but it was still unfortunate). I think this program might assume the user has high resolution widescreen display? (is it usable at 800x600 for example, or on small netbook?)

Share this post


Link to post
Dragonsbrethren said:

  • Clicking on a texture in the texture browser only sets the texture for the first sidedef, even if the cursor was placed in one of the fields for the second sidedef.

I think it wants to be smart, and only change the first texture that is required (or both upper and lower if they are the same).

Share this post


Link to post

@hex11: configurable keys is on the WISHLIST, though I'm still thinking about how it will be implemented. Also the minimum resolution for Eureka is 800x600 (need to say on the website too) -- I will probably stick with that, though the LineDef panel doesn't really have enough room for the extra Hexen stuff.

@dragonsbrethren: firstly, thanks for the very apropos and organised critiques, some replies:

Texture browser: originally I planned to drag-n-drop the textures from the browser onto the sidedef part, but that is very difficult to code with FLTK, so another plan was to click on a sidedef part (might be shown with a red border) then click on the texture to copy it there. But what I ended up doing was a left click would set the LOWER, middle click would set the MIDDLE, and right click would set the UPPER -- and it would choose the side which was actually visible (e.g. where the floor is lower than the back) -- and you hold SHIFT key to set the opposite side. An extra bit of logic is that if the upper and lower are the same and you left click, it will change both -- good for windows. For sectors you left click for the floor and right click to set the ceiling.

Now... that scheme could still be changed or improved (e.g. with the earlier plans), and I don't mind having an alternate scheme (maybe selectable by a config setting) -- though at least the above system is quite economical on clicks. I'd be interested in your thoughts after trying the above.

Building nodes: there was an issue, since the edited wad needs to be closed (as the node building will replace that wad with a new one with extra lumps in the wad directory). Though I just added code to re-open the wad and reload the map (and if I fix the checksum issue, many settings will be restored as if nothing had happened).

Mouse Insert: I like the idea, but does conflict a bit with how things currently work (e.g. clicking in an empty area unselects the current selection). I will consider it though, perhaps for the middle mouse button.

Grid: I use the solid grid lines most of the time too. The separate color for 64x64 is a good idea, as well as configurable colors.

Multi-select: yeah that may be good (will need to try it for a while). I wish though there was a good key to deselect everything, I originally planned SPACE for that (a space is empty) but that became the add/insert function, so perhaps ESCAPE is a good key? (would make sense for vi users, hehe).

On the topic of ESCAPE key : FLTK programs generally use the key to quit the program, it's actually the default behavior and you need a bit of code to prevent it. I don't mind using it for another function though.

Merging linedefs and vertex modes: well I was thinking about that before the release, and it does complicate the code a lot, because right now only one kind of object can be selected (the same as the editing mode), and this would allow two kinds of objects. It probably would be better, but it'll be a big coding job to implement it.

Will leave it there for now, will tackle some your other points later.
Cheers

Share this post


Link to post
andrewj said:

Texture browser: originally I planned to drag-n-drop the textures from the browser onto the sidedef part, but that is very difficult to code with FLTK, so another plan was to click on a sidedef part (might be shown with a red border) then click on the texture to copy it there. But what I ended up doing was a left click would set the LOWER, middle click would set the MIDDLE, and right click would set the UPPER -- and it would choose the side which was actually visible (e.g. where the floor is lower than the back) -- and you hold SHIFT key to set the opposite side. An extra bit of logic is that if the upper and lower are the same and you left click, it will change both -- good for windows. For sectors you left click for the floor and right click to set the ceiling.

That's actually pretty clever, I guess the main problem is that this behavior is not explained in the readme file. But you should still somehow mark which texture will be changed. When both the floor and ceiling of a sector are lower than those of an adjacent sector left-clicking will change the lower front texture and right-clicking the upper back texture (or the other way around), which of course makes sense but isn't really intuitive.

Also you really need to make the texture browser scroll faster with the mouse wheel. I have to scroll about half a dozen "clicks" to scroll past one texture.

Changing the sector floor height doesn't work on my german QWERTZ keyboard layout, where you have to press Alt Gr to type {, [, ] and }.

Share this post


Link to post

Just tried to compile it on Windows and it was easy enough (using MinGW). Mainly consisted of changing the makefile to let it know about additional libs needed for the linking stage. The only change I had to make to the code was in main.cc's Determine_HomeDir function, looks like GetExecutablePath is some Microsoft extension and is not known to gcc, so I just replaced it with an static path ;)

[edit] Of course it does not just compile, it also seems to run fine.

Share this post


Link to post

The texture selection thing is a cool idea, but i wonder how many people have 3-button mouse. The Emulate3Buttons hack (click both buttons at same time) works, but it's not ideal, and you could get the timing wrong and then have to undo. Maybe if they hold down a key (Control or something) and click left button, that could also function as middle button.

Hope there's an "undo" also. :-)

Share this post


Link to post
boris said:

Also you really need to make the texture browser scroll faster with the mouse wheel. I have to scroll about half a dozen "clicks" to scroll past one texture.

Is this actually a problem with Eureka itself? I have this issue across the board in Mint and haven't found a reasonable solution (what little information I find about scroll wheels is about a bug where they scroll too fast, exactly the opposite of the problem I have).

---

Pretty interesting design on the texture browser; I never would've figured that out on my own. A middle click requirement would stop me from using Eureka on my laptop. I doubt I'll actually use it on there much, but it's something to consider; there are still people without three button "mice".

Doom Builder uses c to deselect everything. I find myself hitting that all the time when using Eureka, only to remember I have to click blank space instead.

Share this post


Link to post

Gonna reply to stuff backwards :)

The backquote ` key also deselects everything (CTRL-U too). I have gotten used to the backquote key, it's quite easy to find without looking as it's at the top-left corner of your US keyboard. The 'c' key makes sense too, but I'll keep it on backquote for the default and think some harder about key configurability.

Speeding up mouse wheel in browser will be easy.

Middle click will never be a requirement. Only three functions now: (1) inserting stuff (same as SPACE or INSERT keys), (2) scale/rotate stuff -- will be possible via the menu, (3) setting middle texture on two-sided lines -- can enter texture manually or I'm going to implement the suggestion where you click on a sidedef part (or sector part) and then can clck normally in the texture browser to copy that texture there.

Oh yeah, you definitely can change stuff in the panels when the 3D view is active, and some keyboard functions work too (especially Undo/Redo). Also the right click to change a back sidedef is not unintuitive when you are looking at that wall in the 3D view :)

GetExecutablePath is not a windows thing, I just left it out of the code (didn't think I'd need it).

I will probably keep upper and lower sidedefs in their current order, as it matches the mouse buttons nicely. Could be an option if it was a big deal. What I originally tried was to have them vertically (makes sense to have the upper on top, etc), though that layout didn't fit well in the limited space.

Thing radial buttons for setting the angle : done! (with arrow buttons).

WASD in the 3D view and 'g' for toggleable walk mode : done

3D view cannot grab the mouse, as mentioned previously you can change things in the panels when it is active. Hmmm, perhaps a key (or mouse button) to toggle a "grab mouse" mode?

As for pressing ESCAPE to get out of 3D mode -- I used to do that a lot too, because my 3D view code for Yadex worked like that. However if you think about how TAB in DOOM toggles the view between map view and 3D view, it should help getting used to using TAB as a toggle.

Share this post


Link to post

Multi-select : I just tried this out, and it has issues.

The main problem is with moving stuff -- you click on a thing (selects it), move it (so far so good), click on the next thing (selects that), move the next thing (uh oh, we are moving the first thing too because it is still selected).

Now you can deselect everything after a move, that makes moving individual things work nicely again, however it means you have lost the selection and so you cannot undo the move and try it again (or maybe you wanted to edit those items afterwards).

Making the selection part of the Undo/Redo system is not a place I wanna visit (mucho coding pain).

Hmmm, maybe could set a flag after moving something that forces the next select to clear the existing selection.......

Share this post


Link to post

I'm trying to link GLBSP on OS X 10.7 using Xcode, but it fails to link to some ZLIB (!) functions… I'm compiling its source code alongside Eureka's, which works (I have the FLTK Xcode framework and it works), but the linker can't access deflate, deflateEnd and deflateInit… Here's the error log:

EDIT: oh look, I had to also include fltk_zlib.framework in the project :D It compiled, but naturally, it wouldn't run, because I didn't supply the auxiliary files (.ugh and others) to the project.

Maybe I'll also need to supply my version of the main module if I want the app to run natively.

EDIT: it is totally intolerant to unknown command-line parameters. Are they required for anything, though, or can you operate everything from the GUI?

I'm quaking of excitement. I feel and hope I can make it.

Share this post


Link to post

Success, I made it run on Mac :D


I split the main function into 2 parts to be called from the applicationHasFinishedLaunching: and applicationWillTerminate: methods of the app delegate. I set both home_dir and install_dir to the .app first level below. I disabled command-line parameter support because the execution seems to shove some that cause Eureka to abort (by design).

Now to see if it's stable and if whatever's called from applicationWillTerminate: doesn't crash the game.

EDIT: well, it does seem like the display refreshes very slowly (too rarely): I hit the zoom-in key, and it takes it 10 seconds to refresh. Same with opening wads. On this first execution at least, it's not very usable, due to the huge lag.

Share this post


Link to post

Congrats printz for getting it to compile and run!

I remember that MacOSX supplies a funny argument to programs, something like -psn with a id number attached (i don't remember exactly). If you can tell me what the option is, I can add the code to ignore it.

Command line parameters are currently required to specify the exact iwad (e.g. doom instead of doom2) and to specify the port (e.g. boom vs vanilla) -- these will be settable in the GUI eventually though.

The lag thing -- I vaguely remember hearing about that, it's something to do with the video system in the latest MacOSX OSes, perhaps the "retina" stuff. There is a way to turn it off and the program will run normally. I guess google around, and if it requires some extra code then I'm happy to add it.

BTW your pic isn't showing.

P.S. LibSDL has some MacOSX handling stuff in it, see src/main/macosx/SDLMain.m
(the .m means an objective-c file, as you probably know)

Share this post


Link to post

On Gentoo I had to help the compiler a bit.
I had to add -I/usr/include/fltk-1 to CFLAGS,
and -L/usr/lib64/fltk-1/ to the LDFLAGS.

Right off of the bat I found it kinda weird that it doesn't like to run from inside of its compile environment, and exits out with "FATAL ERROR: Unable to find install directory!"
When I did install it it worked but running from the source directory should work as well I think. Most if not all programs allow you to do that.

Second, likewise for the german QWERTZ keyboard, the AZERTY keyboard in Belgium doesn't allow us to type either [, ], { or } without alt-gr. And no I can't actually use these as of now in eureka.

Besides that I'm kinda glad that there's actually someone who wants to create a working level editor in Linux. The only other editor I got to work in Linux a while back was SLADE. Yadex seems to be crash happy on a 64bit install...

Share this post


Link to post

The Gentoo thing is a bit odd, seems like version 1.3.0 of FLTK is not the one that gets installed into the normal place, maybe because a different version (like 3.0) is?

Anyway, cheers for the info, will add it to INSTALL.txt

Getting Eureka to work without installing it should be easy....

Share this post


Link to post

Yeah, I kinda tried compiling & running it before i went to work. So i didn't have all the time in the world to check out the source code :P.

Currently Gentoo doesn't provide anything upwards of 1.3 of FLTK. It used to provide a 2.0 beta ebuild but that got removed for whatever reason.

* x11-libs/fltk
     Available versions:  (1) 1.3.0-r1
	{{cairo debug doc examples games opengl pdf static-libs threads xft xinerama}}
     Homepage:            http://www.fltk.org/
     Description:         C++ user interface toolkit for X and OpenGL

Share this post


Link to post
andrewj said:

Congrats printz for getting it to compile and run!

I remember that MacOSX supplies a funny argument to programs, something like -psn with a id number attached (i don't remember exactly). If you can tell me what the option is, I can add the code to ignore it.

I think it was something like -NSDocumentDebug but I don't remember the name… Mac users aren't expected to use the command-line for bundled apps, so eh…


The lag thing -- I vaguely remember hearing about that, it's something to do with the video system in the latest MacOSX OSes, perhaps the "retina" stuff. There is a way to turn it off and the program will run normally. I guess google around, and if it requires some extra code then I'm happy to add it.

I don't have a Retina display, and the FLTK menu bar works correctly. However, both the canvas and the inspector sidebar refuse to update the display until I do something like resizing the main window (hiding the window off-screen and revealing it again won't refresh the display).

Alright, I think I solved that. I played too safe and assumed that the main loop would work on the same thread as the application, so I had disabled it. That caused the display to not refresh. But now I restored the main function to contain the whole original sequence, including the loop, which calls that update-highlight function.


P.S. LibSDL has some MacOSX handling stuff in it, see src/main/macosx/SDLMain.m
(the .m means an objective-c file, as you probably know)

I know, it's basic menu-bar, drag-open-file and command-line argument adjustment (getting rid of that -psn parameter), followed by starting the app in a standard way, and then activating the original main function (which is preprocessor-redefined inside the SDL headers as SDL_Main to avoid ambiguity).

andrewj said:

BTW your pic isn't showing.

If you mean that you can't see it, then it's odd. It has some percent encoded unicode characters in it, the link…

Does Eureka use multiple windows (a window per document)?
I wonder if it would be easy enough to port the FLTK menu bar into the native one. Or rather not! I could use the Apple menu bar to extend functionality, since thanks to Objective-C++, I have access to all global variables of the original program. I wonder if, this way, it would be possible to implement AppleScript and Automator.

EDIT: another thing. I had to #define nil as another word, because your program uses it, but it's also a Cocoa keyword (it means 0).

EDIT EDIT: if I replace the default run loop with your main, even if I make sure to load the main interface (nib) file with the menu bar and default blank window, the blank window appears (so the nib works), but the menu bar gets replaced with a minimal one. In short, does FLTK attempt to kill the Apple menu bar for this application, since it's "redundant"?

Share this post


Link to post

Do not use MACOSX as a predefined preprocessor variable; use __APPLE__ [see here scrolling down to MacOS]. MACOSX isn't predefined. With it defined manually, the implemented menu bar is the proper one. Note that your commands add superfluous spaces before the separators:



"EurekaApp" is just the name chosen for this Xcode project.

Other minor things (feel free to disregard them if they hamper you):

* on OSX, redo is commonly CMD-SHIFT-Z, not CMD-Y
* similarly, CMD-H is usually mapped to hiding the window. Here, however, it changes the grid. Probably not worth bothering with, however, as having familiar H for the grid is more important.
* multi-selecting objects is currently done with CTRL. Could it be changed to CMD for __APPLE__, similar to how menu commands are already remapped to CMD? Or use SHIFT as it's more familiar from WinDEU.
* is scrolling meant to zoom in and out?
* ESC quits the app. Since it's so easy to press just to deselect things or get out of unwanted situations, it shouldn't close the program.

NOTE: on further testing, the ONLY shortcut keys which work are CMD-Z, CMD-Y, CMD-C, CMD-A, CMD-U and maybe another one. It seems like they don't override the simple hotkeys (i.e. CMD-V just switches to vertex mode, like V does).

Share this post


Link to post
printz said:

Does Eureka use multiple windows (a window per document)?

Not quite sure what you mean.

Eureka can only handle one wad/map at a time, though you can have multiple instances of Eureka running at the same time.

For the native menu, FLTK provides a special class for this -- as I think you discovered already. I don't understand how it works. But for how it looks, FLTK lacks a way to make nice separators in the menus (there is no extra gap above or below the separator, which looks bad) hence I've added a blank entry to the menus -- but it's easy to disable them conditionally (#ifndef __APPLE__).

For 'nil' : can I rename it to 'Nil' ?

Do not use MACOSX as a predefined preprocessor variable; use __APPLE__ [see here scrolling down to MacOS].

OK, will fix that.


* on OSX, redo is commonly CMD-SHIFT-Z, not CMD-Y
* similarly, CMD-H is usually mapped to hiding the window. Here, however, it changes the grid. Probably not worth bothering with, however, as having familiar H for the grid is more important.
* multi-selecting objects is currently done with CTRL. Could it be changed to CMD for __APPLE__, similar to how menu commands are already remapped to CMD? Or use SHIFT as it's more familiar from WinDEU.
* is scrolling meant to zoom in and out?
* ESC quits the app. Since it's so easy to press just to deselect things or get out of unwanted situations, it shouldn't close the program.


In the current SVN, multi-select is now normal behavior.

Scrolling the mouse wheel is meant to zoom in and out.

ESC quitting the app is default behavior for FLTK programs, but I'm going to disable it.

I'm not sure how CMD needs to be handled, do you know which modifier key FLTK converts it to? It will either be FL_ALT, FL_META or FL_CTRL. I will need to do some research on it....

Share this post


Link to post
andrewj said:

Not quite sure what you mean.

Eureka can only handle one wad/map at a time, though you can have multiple instances of Eureka running at the same time.

Yeah, I mean being able to open multiple documents, each one with a selected IWAD+PWAD, so you can have two wads open at the same time etc. I can see the complications though. You'd have to change all global variables that deal with the currently open WADs, to document class members.

For 'nil' : can I rename it to 'Nil' ?

No, it appears that Nil is reserved too :P From "objc.h":

#ifndef Nil
#define Nil __DARWIN_NULL	/* id of Nil class */
#endif

#ifndef nil
#define nil __DARWIN_NULL	/* id of Nil instance */
#endif
NIL might work, the symbol didn't lead anywhere.


Scrolling the mouse wheel is meant to zoom in and out.

If it's scrolling too fast, can I change it in config. settings? I saw some percentages there, they seem to be implemented.


ESC quitting the app is default behavior for FLTK programs, but I'm going to disable it.

I was able to disable it simply by commenting the part that tests for its keypress and quits if so.


I'm not sure how CMD needs to be handled, do you know which modifier key FLTK converts it to? It will either be FL_ALT, FL_META or FL_CTRL. I will need to do some research on it....

I think it's Meta. Both Windows key and Command key Wikipedia articles mention "meta key", and one often is used as a substitute for another when changing systems.

Share this post


Link to post
printz said:

If it's scrolling too fast, can I change it in config. settings? I saw some percentages there, they seem to be implemented.

How can it be too fast? Each "click" of the mouse-wheel will zoom in or out a single step, the same as the '+' and '-' keys on the keyboard. I hope you're not gonna say that Apple mouse-wheels are different than PC ones :-)

Finer steps would be possible, but the 'Scale' button at the bottom of the window is not going to show the real scale, or provide the same functionality of fine control. So I think it would need a button or widget which works in a different way.

Share this post


Link to post

I'm using a laptop touchpad (the older kind with a visible button, not the fancy newer ones). Maybe the mousewheel step is translated into a too short touchpad step? It's also in two dimensions (horizontal scroll), and if I had a newer kind, I could also use pinch gestures for zooming (I THINK). Does FLTK understand mouse with secondary wheel, and/or touchpad horizontal scrolling?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×