FLTK Window Icon issues, plus Xft anti-aliased fonts in FLTK

[MikeLockmoore]

I've been trying to get a custom window icon for flPicSee (to replace the default red X), but I am not getting anywhere in TinyCore.  I've posted the issue on the FLTK forum, and got back some replies, but nothing useful so far.  If I compile flPicSee with the window icon stuff on Fedora 7 Linux, it can see a new icon!  But not in TC 1.3, and not in Puppy 4.1.2, where I rebuilt FLTK 1.1.9 from source.  I'm still hopeful someone can shed some light on this.

By the way, when I built the FLTK libs in Puppy, I used both the --enable-shared and --enable-xft config options.  The first allows linking apps to a shared library (which is how flPicSee can be so small).  The second uses the Xft font anti-aliasing rendering library, which really helps all text in FLTK apps look better.     The nice thing is, it does not bloat up the FLTK libs much.  libfltk.so.1.1 went from 628,499 bytes (no Xft) to 632,100 bytes (with Xft), an increase of < 4K and about +0.6%. Seems worth it to get smoothly-rendered text, as far as size.  On low-end hardware, Xft would perhaps impact performance and slow screen updates.  But I wonder how much?  I hope it seems worth it and this FLTK+Xft support can be added to TC 2.0 (if it is not there already).

I've attached a screen shot of the FLTK forms demo, showing the generally-nice appearance of the Xft-rendered text (although I compressed this .JPG a bit, so it's image quality is not as good as the original on my screen).
--
Mike L. 

[curaga]

While Xft doesn't add much to FLTK, it does add both expat2 and fontconfig (total 160kb compressed, about ~500 uncompressed)

[MikeLockmoore]

Thanks for pointing out the trade-off, curaga.  Maybe we could put together a TCE that includes those items and a recompiled FLTK as a "Smooth Font FLTK" TCE/TCZ?  I think a bunch of people would go for this if the whole thing was < 1 Mb and their hardware is < 5 years old or so.

roberts: If you are reading this, did you try to have any of the base apps set a window icon?  I notice that cpanel, appbrowser, and terminal all have the default red X window icon in version 1.3.  Was this by choice, or did you encounter the same failure for the window icon to appear?  I got a custom icon to appear when I built flPicSee in Fedora with their version of FLTK, so it is possible.  I also notice Gtk apps in TC 1.3 can show a custom window icon.  So maybe Xpm needs to be built with different options?  I know this may be a fairly low priority, but I'll try to interface with the FLTK community to see if we can find a root cause.
--
Mike L.

[roberts]

I don't use a window manager that displays a window icon.
However, the default red X is fine by me. Custom icons are a little too much eye candy.

I do agree with Curaga, that adding xft is too large for the stated goals of Tiny Core.
It is better left available via extensions.

[tobiaus]

Maybe we could put together a TCE that includes those items and a recompiled FLTK as a "Smooth Font FLTK" TCE/TCZ?

if i understand that should not be necessary. all you do is create the xft extension, and then add expat and fontconfig to its dep file (they already exist.) for your app that hypothetically uses xft, you would simply add xft, and fontconfig, and expat to your app's dep file. the recompiled fltk would be the same issue, but i don't know if we're talking about something that makes it necessary to have two fltk's being linked to dynamically, if that's possible.

[Jason W]

Fltk or any other lib that exists in base in /usr/lib could be recompiled with more features or updated and installed into /usr/local/lib as an extension and the lib in /usr/local/lib would be the one linked to after the extension is loaded.

[MikeLockmoore]

Tobiaus:  Jason explained my idea... if a user installs the "smooth font" TCE, it would replace the stock FLTK version in the base system with one compiled with Xft support, and pull in the other dependencies to make that work.  All the FLTK apps that dynamically link to the FLTK libraries would automatically use the new version, and would therefore start showing the smoothed fonts.  I do not want to make flPicSee depend on this smoothed font stuff... it is supposed to be small and work with the base system.

roberts: You are using FLWM normally?  Is that likely to be the base WM someday instead of JWM?  Does that work well on the Dell Mini?

EDIT: I just learned from "Greg" on the FLTK forum that I don't need to have any code for the window icon in my application... I can just do what other add-on apps do: put the image file and a config file in /usr/local/tce.icons.  Maybe this would not be done in TCB if flPicSee remains the default image viewer.  But it could be done if flPicSee is later an optional app.
--
Mike L.

[roberts]

roberts: You are using FLWM normally?  Is that likely to be the base WM someday instead of JWM?  Does that work well on the Dell Mini?

Yes, I have a slightly modified flwm.tce (logout calls exittc) that I use exclusively.

In the next RC, v2.0rc2, I have factored out all JWM specifics from core components of Tiny Core.

I have created interface files so that most any window manger can be used and still have updated menu of extensions.

I can drop flwm in v2.0rc2 and it works. There are some minor annoyances, such as the mouse cursor changing to 'move' when it should stay 'arrow' in certain areas of window navigation. The dynamic menu seems only to be such  when actually editing menu directory items. I have a work around 'Refresh Menu'  menu item.

flwm compiled with shared libs is tiny compared to jwm. About one quarter the size of jwm!

I find that I work faster with flwm than jwm. I like the combined menu of app launcher, task manager, and pager/desktops all on an anywhere available popup. However, many users are used to the Microsoft style of  window managers, so I think there would be resistance.

My thought was to try to move to flwm, as it fits with my minimalistic philosophy and let jwm become an extension. That way jwm could be compiled with all the rich features users have come to expect, menu icons, xft fonts, etc. Currently, I have compiled jwm to be as minimalistic as possible.

With the 'no wasted space' of flwm, it is ideal on my Dell Mini 9. I think the most attractive aspect of flwm, for me, is the no wasted 'eye movement' and litlle cursor movement. With task bars, you have to constantly change your vision, to access them, either up or down and or move windows out of the way. With flwm, the popup, is always close by resulting in quicker time for me. Perhaps, it is my disability, OPMD, that makes flwm a better fit for me. For me to change focus is getting slower and slower.

Are you familiar with flwm, want to volunteer to patch some of the annyoances that I have listed above?

[tobiaus]

However, many users are used to the Microsoft style of  window managers, so I think there would be resistance.

it's not similarity to win 95 that makes jwm preferable, it's the reliability. also it's simply bad design to have the title bar sideways, so that it has to be read sideways. the design makes sense on tiny screens, but i think most people still compute on normal screens. if a couple years from now more than half of everyone is using macbook air size netbooks and smaller... then it would make sense as a default over jwm.

the two most important factors in choosing a default window manager for tc: how lightweight/fast it is, and how many people are going to want to install something else. both are tiny, i actually think flwm would turn a lot of people off tinycore. even though most of us are a sort that install the wm we like if we don't have it installed, lots are not like that. if they don't like the wm enough, they won't settle, they'll move on.

first impressions count. flwm won't make one. there won't be a noticeable speed difference, but it won't be as "friendly." we're not just talking about microsoft, but the history of gui design. so long as i have jwm.tce handy, it's just one more little thing to install when i'm in cloud mode, i'll manage. but yeah, you're going to turn off people with flwm. you've taken plenty of chances though, and you can always take one more. i think jwm makes tc look good. i promise not to mention this again.

[roberts]

That is a pretty weak argument. So it must "look" like Windows? You have no concerns about functionality. With jwm I am always having to move windows. You are OK with the bugs in jwm, the fact that OO and mtpaint open under the task bar. A new user would know that you use alt-left to drag move to access the application's menu.  Is alt-left drag to move a window, also a Windows featrue? And no full screen mode with flash or other video players is still better than those awful sideways title bars. Hmmm.

[jpeters]

Does flwm allow editing hotkeys and tray buttons?  I hope it doesn't have to be recompiled for changes (the impression I got from google searches).   

BTW/ Robert....you and Lucky13 seem to have a lot in common ....

[roberts]

I have not heard from Lucky13 in quite awhile. Does he too like flwm?
Last I heard he was enjoying and blogging about an acer aspire one.
He did create our Tiny Core logo. Did a nice job too!

No one, except Team Tiny Core, even knows what options I have set in flwm, so arguments against something you have not seen is rather fruitless.

A major feature of 2.0 is support of other window managers. It is just like many of you grab bash because you don't like our default of the ash shell. Or coreutils because you don't like busybox. So even if flwm or other minimalistic WM is chosen, or even if jwm remains, you will have multiple choices to 'grab' some other WM.

I have had to hear of the bugs in jwm, and requests for fluxbox. Then too, I choose to use flwm so my motivation was high to make a flwm.tce work with 2.0rc2.

2.0rc2 public release is pending as WM issues are sorted out. No decision has been made. Even when a decision is made because we are at release candidate level it could be reversed.

[MikeLockmoore]

roberts:  No, I am not familiar with flwm.  I have looked at some online descriptions of it, but I have not tried to load and use it, and I have not reviewed the source code for it.  But perhaps I could look into patching it, if I know exactly what the issues are and what is needed.  I don't know if I can put a lot of time into it within the timeframe for 2.0.  Or maybe 2.0 will come out whenever its ready, so there's time to resolve the issues you described?

As a side-note, I am supposed to get a Dell Mini-9 at work soon.  I'll probably initially work with the installed version of Ubuntu, but if I find it too slow, I may try to boot and use TC, maybe as a guest OS.  Could I install and boot it from an SD card?
--
Mike L.

[jpeters]

I have not heard from Lucky13 in quite awhile. Does he too like flwm?

No one, except Team Tiny Core, even knows what options I have set in flwm, so arguments against something you have not seen is rather fruitless.

flwm was discussed in:   

http://damnsmalllinux.org/f/topic-3-35-19598-0.html
__________________
Good tips on JWM options, Lucky13.

I quite like the borderless windows and controlling them via keyboard or taskbar. That setup does save screen real estate and actually helps me because of my severe ptosis. Less eye movement for controlling windows. It almost gives a MacIntosh like behaviour.
____________________________

No arguments against flwm.....just inquiring whether you can add hotkeys/tray buttons...since I use both. It wouldn't matter to me if it didn't, since I'd simply load my own wm...

[roberts]

As a side-note, I am supposed to get a Dell Mini-9 at work soon.  I'll probably initially work with the installed version of Ubuntu, but if I find it too slow, I may try to boot and use TC, maybe as a guest OS.  Could I install and boot it from an SD card?

No need to uninstall Ubuntu or boot TC from SD. I just made a directory called tinycore off the root of ubuntu, copied bzImage and tinycore.gz. I made another directory called tce, then added an entry in the existing grub menu.lst. So easy. You will like it, as it makes the Mini 9 ready to use so much faster than waiting for Ubuntu to load up.