Poll #13

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Show All Polls | Show Comments | Submit Comment ]

Poll #13

Most important schemes/themes to provide in FLTK 2.0 (in addition to the current FLTK look-n-feel)?
Windows 266 / 12%
Windows XP 479 / 22%
GNOME Default 282 / 13%
KDE Default 340 / 16%
Aqua 512 / 24%
CDE 36 / 1%
Motif 66 / 3%
SGI 78 / 3%
Xaw 15 / 0%
Other (post comment) 46 / 2%
2120 total votes.
This poll is closed.

User Comments

Submit Comment ]

From Anonymous, 00:36 Jan 30, 2003 (score=5)

The most important point is to allow EASY customization of the theme.  Gradients aren't too popular or even necessary for the skinning community - just regular old images / tiles produce great skins.

Next, users of fltk programs will react depending on whether the interface looks better or worse than the native OS.  If it looks better, streamlined but with nice eye candy (hence the popularity for Aqua), the users will not be turned off by an 'ugly non-native look', but will rather view it as an exciting new technology.  There's a fine line between the ugly and the beautiful.  I suggest an 'fltk' look that is smooth and liquidy like Aqua, but favoring white/grey tones and having neutral appearance, so users are not offended by the blatent skin of a single OS.

Finally, if images are going to be used, then have a competition for the best skin, which would become the official fltk skin.
Reply ]

From novi, 17:26 Oct 04, 2004 (score=4)

I would love to see XP themes support. In the future aqua would be great too.
Reply ]

From Anonymous, 15:57 Sep 25, 2004 (score=4)

I think fltk should use its own themes, but should use system colors by default so that applications will not look entirely out of place on a given target platform unless the default theme is overridden.

There should also be a set of api calls to set the base rendering features of a theme.

I don't think that I would appreciate as robust a theme management system as gtk+ uses.
Reply ]

From Anonymous, 05:28 Mar 31, 2003 (score=4)

I like fltk because it is simple and light and i think that schemes/themes are not essential. Adding such features will weigh down fltk and (if it is not well done) will make application more difficult to port.
Reply ]

From Anonymous, 12:30 Feb 22, 2003 (score=4)

Please, no pixmap themes... They will make fltk slow and bloated. User configurable colors and fonts would be enough. (esp. fonts, try to use a fltk app at 800x600... The menus are HUGE). And maybe some gradients and interlaced lines as in blackbox styles.
Reply ]

From xentalion, 10:38 Dec 11, 2008 (score=3)

Hear hear. Blackbox style widgets would be both beautiful and fast.
Reply ]

From Sean Etc., 18:26 Feb 13, 2003 (score=4)

One thing to remember is that there is a lot more than just look to a platform's GUI.  Things as simple (and easy to forget) as button ordering differs between Mac, GNOME, Windows wanna-bes, etc.  Then consider things like preference backends (Registry, gconf, netinfo), vfs implementations, and the whole UI style (excessive retarded use of right-clicking in Windows vs. very simple and elegant Mac drag-n-drop), and so on.

You'll *never* be able to have a write-once, work 'properly' everywhere toolkit, unless your API is very specific (i.e., for each conceivable operations, provide a pre-arranged, grouped, and styled set of widgets for the specific platform/environment - as soon as a programmer has to manually select an icon or the text for a button, you've become platform/environment specific).

With that in mind, care should be taken to fully tie into the environment in usage, and not just try to pretend you are.  I'd rather have an app that looks like Windows and acts like Windows on my GNOME desktop, than an app that looks like a GNOME app but (confusingly) works like a Windows app.  The look would then provide a large visual clue that indicated what behaviour to expect.
Reply ]

From Georg Fischer, 19:40 Jan 24, 2003 (score=4)

Doesn't really matter to me what kind of theme, the most important issues to me are:

firstly that the easy of customizing the look remains, since I tend to customize it heavily.

secondly that the default scheme is not based on images and/or color gradients because it should be as fast as possible. (I've only had annoying experiences with applications/themes that have image based widgets or gradients. A fancy look is fun the first couple of hours but then it's just annoying that the UI isn't as fast as it should be.)

--GF--
Reply ]

From Alexey Parshin, 12:37 Jan 24, 2003 (score=4)

The particular them isn't that matter. It's important to provide an easy to use way to create themes, may be theme editor/compiler.. Then just make the themes list on fltk.org. It may be useful to make KDE->fltk them convertor, or Gnome->fltk theme convertor..
Reply ]

From Anonymous, 07:45 Feb 19, 2003 (score=3)

Amiga look would be nice :)
Reply ]

From Dejan Lekic, 10:16 Feb 21, 2003 (score=2)

Yeah, but somebody would make it anyway, sooner or later :) there are a lot of Amiga fans around. :)
Reply ]

From sfbell, 20:11 Feb 09, 2003 (score=3)

I think the SGI theme is stylish, and should be available on more than just the SGI platforms.
Reply ]

From hans yperman, 10:33 Jan 27, 2003 (score=3)

Just wondering: do we need this?  The important stuff of the UI is the feel, not the look.  Yes, maybe XP has much cooler round buttons, or aqua is cool for another reason.  But do we want a cool UI or do we want a fast, light  and simple UI?  Besides, The look of your application is much easier to screw if it has to be right on every possible skin.  Also, derived widgets may depend on the default look-and-feel.  So my question is: is this the way we want FLTK to evolve?  Personally, i like FLTK because it does what it has to do, without needing a P2000 to redraw the screen.  If i want a cool widget  set, well, i'd take a heavier and more used one (GTK-- or QT ?).

By the way,is it possible to start a discussion about what needs to be changed at the internals of the library?  Missing important widgets, handy functions, or portable graphic operations?  That would be worth a very very very long discussion.

PS: After rereading, this looks like an angry comment.  It is not.   I would like a discussion, not a flame war.  Apologies to anyone who's ego may have been hurt.
Reply ]

From Anonymous, 07:46 Feb 22, 2003 (score=1)

1.) You probably want a fast, light and simple UI. 2.) Many people want a cool UI. 3.) I want an UI that fits in with the other applications I'm using.

I think nobody who really cares about 3.) currently uses FLTK. For me as a MacOS fanatic ;-) using a FLTK program on MacOS is almost out of the question, because it just won't fit in. It's just no joy to use a FLTK app on MacOS, no matter how great the toolkit feels when used on it's own...

You'll have to decide whether you want to "convert" additional developers&users to FLTK, or whether you want to satisfy the existing users even more. If you want to convince people like me to use FLTK, you have to support "native" look and feel... (on the other hand, you might just ignore me...)
Reply ]

From Mike Sweet, 13:27 Jan 27, 2003 (score=1)

All discussion of FLTK development should probably happen on the fltk.development newsgroup/mailing list.

As for the whole issue of "should FLTK do schemes/themes", it is actually one of the driving forces behind 2.0 and one of the things that has been asked for. Carl's original Fl_Style patch was very popular, and 2.0 builds on that to provide both the original FLTK look-n-feel as well as the hooks for alternate appearances. The implementation is designed for small size and speed, and that's the way we want to keep it!

Providing a style interface allows us to provide either one look-n-feel on all platforms or the platform look-n-feel without changing FLTK or your application...
Reply ]

From Anonymous, 18:04 Jan 24, 2003 (score=3)

Aqua please...
Reply ]

From Anonymous, 14:51 Aug 03, 2004 (score=2)

Hybrid Windows 2000 x Windows XP.

In other words, start with Windows 2000 as the baseline and only take a few bits from Windows XP (like command buttons).  Leave out the crappy-looking minimize/maximize look that comes with XP.
Reply ]

From Iván Hernández, 13:30 May 15, 2003 (score=2)

Metal theme (default in SUN's Java) is missing on the list, and I wonder why... for all times, it has been one of my favourites...

Maybe, it would be great if some kind of Palm theme was available also... (now i'm thinking in embedded device's poll)
Reply ]

From Anonymous, 18:23 Mar 19, 2003 (score=2)

I'd like the Windows (95,98,2k) feel to be available, and I'd also like MacOS X aqua. But when you make a Windows program, a Windows skin would fit more nicely than anything. Aqua just looks cool.
Reply ]

From Anonymous, 14:08 Mar 20, 2003 (score=4)

heh..

the u guys obviously haven't used a mac often, (not expected, they're expensive)

but the Aqua look&feel is superior of them all.

if fltk borrowed some Apple user iterface guideline in their GUI development, i'm pretty sure they'll come out with a neat theme. that would'nt be too hard to use, yet compatible with most OSes
Reply ]

From Anonymous, 16:19 Mar 21, 2003 (score=1)

I've made a set of boxtype drawing functions for FLTK 1.1 that give the Windows XP look for most controls, and increase the non-compressed EXE size by only 8 KB (I used 12 widgets).  Some workarounds the default FLTK look are needed, but the end result is that I have a program that runs on XP and looks (relatively) nice, like XP.  I'm sure that the code size could be optimized down to even smaller, and packaged into a library that does Aqua, KDE, etc.

I strongly advise against native drawing support using OS-specific 'draw widget' commands.  Is it worth compromising the flexibility of the FLTK drawing routines to incorporate ~~1000 lines of code for drawing native Windows widgets?  Others claim that the Windows widgets can be drawn easily and flexibly to memory.  However, the code required for drawing the native widgets, potential bugs introduced, inaccuracies in pixel measurements, etc simply outweighs the cost of SIMPLY MAKING THE SKIN.  Add code for turning most of FLTK's widgets into native Windows widgets, and it's likely that the program will be more buggy, and will probably increase in size by more than 8 KB.

There is a much better, more general solution: Support skinning of the widgets.  If you're afraid of being sued, simply make a license for each skin that says 'this skin MAY ONLY BE USED on system X for the purposes of reproducing a SIMILAR interface to the native interface.'  Windowblinds, Shareaza, Winamp, WiMP, and a million of other skinnable programs have skins SIMILAR to Aqua(R), and the skins are not illegal.  I don't think there is a high risk, so long as no trademarks are used, and the emulated interfaces are similar, not identical.
Reply ]

From Shawn Harrison, 14:06 Feb 26, 2003 (score=2)

I don't care how it looks as long as everything is available through keyboard accelerators. That's one area where Windows wins over Mac, and I've been surprised that some of the Linux desktop GUI developers have not included it consistently.
Reply ]

From Anonymous, 10:35 Jan 23, 2003 (score=2)

I argue against using a Windows look and feel on any platform other than Windows, or even making it available on other platforms.  Microsoft owns that and they do not allow it to be copied elsewhere.  FLTK can provide the Windows look and feel on MS platforms, but I prefer the default theme to be FLTK's own.
Reply ]

From Anonymous, 04:36 Feb 22, 2003 (score=5)

Love it or hate it - Windows is the most commonly used platform so if you want to support those users you need to provide a look and feel they are comfortable with.

If you accept that - then the next step in the argument is that users will want the same look and feel to applications if they switch between platforms regularly.
Reply ]

From Anonymous, 16:49 Mar 04, 2003 (score=3)

Yes I agree with the argument. To coax Windows users to try Linux and for Linux new comers, you have to provide Windows-like windows and style. This is to ensure smooth transition and the new comer will feel good that at least he will not be afraid to try out other non-Microsoft based tools and OSes. This will enable Linux to be accepted and gain support for being free and not geek-like and not be seen as for geeks only OS. You must remember that almost 90% of the world is using M$ OS so to get them to use open source OS and tools is make them easy to use.
Reply ]

From Anonymous, 15:11 Mar 21, 2003 (score=1)

I disagree with this.  If all you do is clone Windows, then there is no real incentive to change from Windows.  Similiarity with gadgets and their function will ease the transition, but your overall GUI design must be better than Windows if you really want people to change.
Reply ]

From Anonymous, 20:55 Mar 29, 2003 (score=2)

Uh, there's still the cost of licensing, and the constant and uneasy feeling that you're at Microsoft's mercy.
Reply ]

From Anonymous, 08:05 Feb 20, 2003 (score=1)

I partly disagree with that. First off, the idea of bringing Windows look and feel to other platforms is surely dangerous. For the second, I have to add, that I found the FLTK look and feel a too average. Not having had the chance to switch to another, mostly the native look and feel, really made me go away from FLTK and I found a Java/Swing solution for that. Anyway, I think it's a good idea to offer more look and feels for developers, so basically just do "the same" as Swing does for Java... less buggy, of course...
Reply ]

From Mike Sweet, 12:05 Jan 23, 2003 (score=1)

Well, the original Windows look-n-feel has been copied so much that the current FLTK, KDE, and GNOME defaults are remarkably similar in appearance.

As for the Windows XP "fisher price" look-n-feel, there is very little innovation there, just a general softening of the button edges and the questionable use of color.

Neither interface is distinctive compared to Apple's Aqua or many other experiments in UI...
Reply ]

From Sean Etc., 18:30 Feb 13, 2003 (score=1)

Windows look and feel isn't that copied in KDE or GNOME, nor Aqua.  Even if you don't notice it at first, when you start using the environments, lots of little design issues creep up.  Note that KDE, GNOME, and Aqua all have detailed Human Interface Guidelines, none of which are "compatible," and if Windows has one, no one seems to use it.  An app that behaves like a Windows app will stick out like a sore thumb in a non-Windows environment.  I notice it every day when I try to use real Windows-UI rip offs like Mozilla or OpenOffice.org, where the entire style of widget usage and user interaction is just plain badly designed, and "incompatible" with my preferred environments (GNOME, Aqua).  The similarities between Windows and any other environments ends at the "they have similar widgets," since the style for arranging widgets, behaviour of widgets, usage of icons, naming of menu items/buttons, etc., are all different.
Reply ]

From Anonymous, 15:01 Feb 04, 2003 (score=1)

There is no such thing as "the original Windows look and feel".  Microsoft has been copying left and right.  Much of the feel comes from IBM GUI specifications.  For the look, Microsoft has copied, at times, from Macintosh and X11 toolkits.  I don't think they have ever come up with anything particular original in the look-and-feel area.
Reply ]

From Lee, 03:35 Mar 05, 2003 (score=3)

In 1981, Xerox initiated a revolution in computer interfaces with the commercial release of the Star Workstation. Its novel use of a mouse to manipulate graphic analogies representations of information through a desktop analogy was picked up  ... well, everyone.
Reply ]

From Anonymous, 06:48 Feb 12, 2003 (score=2)

The one specific GUI appearance "innovation" they had was in Microsoft Excel, when they first decided to give dialog boxes a 3d metallic ("Chisled Steel") appearance, rather than a flat solid color as was seen before. (buttons and scrollbars had already looked 3d, but they extended it to the nearly every GUI element)
Reply ]

From andy, 09:44 May 15, 2003 (score=2)

Now I thought they just copied that from Motif on X-Windows!
Reply ]

From Anonymous, 01:07 Jan 14, 2005 (score=1)

Whatever allows for
     speed
     portability
     stability
     ease of coding
     user friendliness
     .
     .
     .
     pretty
Reply ]

From amora, 09:09 Mar 25, 2003 (score=1)

I like GNUStep look-n-feel very much!!!

But... I wonder myself if there is a way to decouple code & look-n-feel, sth like themes, and everyone can design its own one.

albert...
Reply ]

From Anonymous, 04:34 Feb 26, 2003 (score=1)

I don't want to see windows look-n-feel in other OSes. I want see Aqua-like look in Windows and Linux apps.
Reply ]

From Dejan Lekic, 03:17 Feb 27, 2003 (score=1)

I don't want to see Aqua look-n-feel anywhere but on MacOS X !
Reply ]

From John Mac, 14:50 Feb 17, 2003 (score=1)

Just compiled the 1.0 version after down loading it the other day. I like the smooth designer and clean code generation. I like the lack of project clutter which, to me just gets in the way when using other packages. Fonts tend to drive me round the bend, I think my eyes anone the best for screen wear. In your new realease, please allow for the configurability of 'fonts'. The schematic fonts eg; main menu, menu items, various differently typed dialog boxs, and ofcourse the editor. At the moment i'm tracing through the source for whatever i can tweak in that direction. It's strange, it seems all the diferent packages consistently over look the possibility that other people may prefer/need to use a different font. Or maybe i'm the only one who has been slowly going blind.

Anyway, I really do like what i've found so far with your 'fltk' package. Very refreshing. Good Luck for the future...
Reply ]

From FunkieDaMouse, 15:45 Feb 15, 2003 (score=1)

You should add one with little monkeys as buttons. :0 But seriously... a nice, clean, gradient-based theme would be nice.
Reply ]

From Anonymous, 10:24 Feb 08, 2003 (score=1)

Keramic from kde 3.1 (it looks pretty for me ;)
Reply ]

From Anonymous, 17:39 Jun 18, 2004 (score=3)

I can't stand Keramik!!!
Reply ]

From Anonymous, 15:03 Feb 04, 2003 (score=1)

What about a black-and-white theme, like the old Mac, Smalltalk, and X11 GUIs? Those were clean, and they are really nice in terms of low bandwidth requirements.
Reply ]

From Peter R. Brinkler, 15:04 Jan 31, 2003 (score=1)

I'd just throw in a comment here. How about allowing the themes to be created using svg and have fltk being able to draw the ui using the svg specified, I see several benefits to this, for instance the ability to create a ui that is able to scale over the resolutions that the users might use. A certain opensource project that I am part of have been debating whether to use fltk or the mozilla ui framework for next gen of our ui. While I have been the major proponent for fltk during the discussion I certainly see the benefits of having the components drawn using svg. Yes, I know this it probably difficult to implement, especially portable over all the mulitude of platforms people want to run fltk on.

Well just my dkr 0.25....
Reply ]

From Anonymous, 04:54 Jan 28, 2003 (score=1)

It seems to me that there are two important issues here: one is that Microsoft dominate the current (and I'm sure, near-future) market - and so many many people will need to provide a look-and-feel which emulates MS on MS platforms; the second is that most MS technology is sadly poor (for assorted reasons) - and we need to generate something much better to break that monopoly.  This leads me to think that it is very important to support MS's assorted look-and-feel's - whatever we may think about them - while ensuring that the underlying technology is so much better than MS's that a critical mass of developers use non-MS tools.
Reply ]

From Thomas Geijtenbeek, 06:56 Jan 27, 2003 (score=1)

I believe it would be a good idea to implement a skin that uses the OS' 'own' special functions to draw the controls. I know this is possible for windows, don't know about other OS's. This might harm platform independance, but it does make your application's look consistant with the rest of the OS (whatever theme it uses). Skinning can be nice, but if your FLTK-program is designed for a single OS, a 'true' native look can be just what you want.
Reply ]

From Mike Sweet, 08:50 Jan 27, 2003 (score=1)

Actually, I don't know how you'd just draw a Windows button without having Windows manage the UI control.  Things are a bit more complicated when you try to use the underlying GUI APIs, which is why wxWindows is such a mess...
Reply ]

From Thomas Geijtenbeek, 02:45 Jan 28, 2003 (score=2)

In the Windows GDI you have a function called DrawFramControl(), which draws 'windows-style' buttons, checkboxes, scrollbars, etc.
Reply ]

From Mike Sweet, 05:45 Jan 28, 2003 (score=1)

OK then, it should be trivial to write the necessary style drawing functions for all of the standard controls...
Reply ]

From M Evans, 16:38 Feb 04, 2003 (score=1)

I've been involved with similar debates for a long time.  There are zillions of reasons to avoid native widgets.  Use your own, and just theme them to look like the OS.
Reply ]

From Thomas Geijtenbeek, 04:59 Feb 06, 2003 (score=1)

I agree, but that wasn't the point here. I only pledged for the use of native widget-drawing-code, not native widgets.
Reply ]

From Anonymous, 06:49 Feb 09, 2003 (score=3)

Native widgets are "opaque" so you are stuck with the OS API to use them.  I seriously doubt that either Windows or Mac offer APIs just to draw widgets without dragging in the whole event model and everything else.  It's best to control everything in the toolkit, and not that hard.
Reply ]

From Anonymous, 07:29 Feb 22, 2003 (score=2)

Both MacOS and Windows offer APIs for just drawing widgets, without using the MacOS/Windows event models.
Reply ]

From Anonymous, 01:26 Jan 27, 2003 (score=1)

fltk's own
Reply ]

From Dejan Lekic, 05:06 Jan 27, 2003 (score=2)

I think Mike should add "FLTK's own" as option... :)
Reply ]

From Mike Sweet, 06:53 Jan 27, 2003 (score=1)

Perhaps I should clarify the question in the poll; these schemes/themes would be provided in addition to the current FLTK stuff.
Reply ]

From Ilia Jeliazkov, 09:03 Jan 26, 2003 (score=1)

It would be great if FLTK has its own customizable and modern look-n-feel that is still fast and light.
Reply ]

From Anonymous, 06:25 Jan 25, 2003 (score=1)

I think FLTK should have its own unique look and feel, but can provide  the option to emulate other environments, for those who want.
Reply ]

From Anonymous, 14:42 Mar 02, 2003 (score=4)

Why create one more mediocre look&feel? as if there are not allready too many to chose from.

The user is helped by standard look&feel (windows being the de-facto standard?) and doesn't need yet another choice.

Do you think that the user should recognize that something is "different" with an application that uses fltk? This would be for me an argument agains fltk. I want just what the user expects.
Reply ]

From Dejan Lekic, 11:17 Jan 25, 2003 (score=2)

I agree with this to the maximum!
Reply ]

From Anonymous, 12:33 Jan 30, 2003 (score=4)

i completely agree fltk should have it's own nice and fast theme but also allow easy configuration/selection of the native os theme.... Anyway, if the default fltk theme is nice enough most of the users would  just prefer to use it instead of the native os themes.. as for the question about how the official fltk theme should look like, why don't something nice and simple with gradients in some cases to spice it up a little like the mozilla pinball theme, or the qnx photon gui, or otherwise something faster/simpler like something on the lines of redhat's bluecurve or java's swing....
Reply ]

From Szasz Pal, 03:14 Mar 18, 2003 (score=1)

Lets make a contest to create the default, original FLTK theme/style
Reply ]

From Dejan Lekic, 11:45 Jan 23, 2003 (score=1)

IMHO Motif theme is _A MUST_ ...
Reply ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.