Page 13 of 14

Posted: Wed 31 Dec 2008, 08:49
by Aronzak
"software" That seems a little redundant. But I do like the theme, and the buttons that say "puppy".

Posted: Wed 31 Dec 2008, 09:05
by ttuuxxx
Aronzak wrote:"software" That seems a little redundant. But I do like the theme, and the buttons that say "puppy".
Are you also going to the fireworks in Sydney?
I'm going to the 12:00 show with the wife and daughter
ttuuxxx

Posted: Wed 31 Dec 2008, 18:21
by ttuuxxx
Ok guys here's the latest icewm with, the Jwm restart with icewm, The new theme, Hope WhoDo likes it :) and the pwidgets fix for icewm.
things left to do
-make a new desktop icon for the taskbar
- figure out how to the seamless switch works for icewm so that I can use it for Jwm and also use it to copy a file for Jwm
ttuuxxx

Ps I might remove the jwm to icewm from the package and make it a separate package for 3 reasons.
- Its a JWM problem not Icewm
- to keep this version of icewm as small as possible
- easier to fix/update the package and less complicated :)

Posted: Sat 10 Jan 2009, 12:54
by rarsa
Coming quite late to the thread.

I'd suggest more contrast in the menu. Light gray on dark gray sometimes is difficult to read. Same with the highlights.

The background colours seem OK, it's just the fonts which could have more contrast.

http://www.infoq.com/articles/Colors-UI

Posted: Sun 25 Jan 2009, 14:41
by HairyWill
Because Ptray contains patched versions of fixmenus, globicons and I think some other files it is probably important the order in which this is installed with other pets when building an iso. Personally I think that Ptray would be improved if these patches could be added to the original packages rather than in Ptray. this should also lessen the risk of forking.

Posted: Sun 25 Jan 2009, 22:45
by WhoDo
HairyWill wrote:Because Ptray contains patched versions of fixmenus, globicons and I think some other files it is probably important the order in which this is installed with other pets when building an iso. Personally I think that Ptray would be improved if these patches could be added to the original packages rather than in Ptray. this should also lessen the risk of forking.
Could this be the source of my problems with JWM rebuilding .jwmrc with "null" for top-level icons? :shock:

Posted: Mon 02 Feb 2009, 12:06
by HairyWill
WhoDo wrote:Could this be the source of my problems with JWM rebuilding .jwmrc with "null" for top-level icons?
I don't know.

Sigmund
How about using the .desktop files in /usr/share/applications to drive the ptray configurator and also the drag icon to desktop function. This would avoid having to put lots of extra files or symlinks in /root/my-applications/bin and would also allow it to recognise new applications that had been installed. I would like to make more use of the .desktop files in roxrightclicks as well especially as properly completed .desktop files should contain a list of the mimetypes that they work with. I will probably end up writing some rules to drive a script to complete the mimetypes in the .desktop files.

Posted: Mon 02 Feb 2009, 13:39
by zigbert
HairyWill

The symlinks in /root/my-applications/bin are generated from .desktop files (see /usr/sbin/fixmenus). They are updated when you install a new app, but if the Globicons file doesn't has info about its icon it will show up with a general rox-icon. Why I don't use the icons in the .desktop files is simply because they point to a 16x16 pixel icon instead of a 48x48.

WhoDo
Could this be the source of my problems with JWM rebuilding .jwmrc with "null" for top-level icons?
Could I reproduce this issue with the Puppy 4.2 alpha2

Sigmund

Posted: Mon 02 Feb 2009, 16:28
by HairyWill
zigbert wrote:The symlinks in /root/my-applications/bin are generated from .desktop files (see /usr/sbin/fixmenus).
Oh I see , I should have looked more carefully. So at the moment you have to hardcode some entries into globicons. If an application has a .desktop file that points to an icon in rox-filer's icon path it doesn't need an entry in globicons. Maybe it would be sensible for puppy to move to applications supplying more complete .desktop files (containing translations as well). I appreciate that this will have a size impact with over 100 .desktop files. What do you think. Fortunately for roxrighclicks it only needs 16x16 icons anyway.

I am also interested in whether application icons should be determined by the application or by the theme. The difference between generic, browser, and specific, seamonkey, is important here.

Posted: Mon 02 Feb 2009, 18:36
by zigbert
It is always troublesome when we realize that old standards or OLD. Like our .desktop files. They should of course include locals and link to big icons. It could be several icons with different priority. Puppys default theme could be generic and have 'browser' icon, but user can install extended icon(set)s that contains 'firepup' icon. If .desktop had info about both specific icon (firepup) and generic icon (browser) it supports both approaches.

But this means we have to make a Puppy-icon-standard. Then translate and repack all Puppy packages. Maybe this is better suited for Puppy5. The far easiest approach would be to add more info in the Globicons file for the most common programs.

Sigmund

Posted: Mon 02 Feb 2009, 19:38
by WhoDo
zigbert wrote:WhoDo
Could this be the source of my problems with JWM rebuilding .jwmrc with "null" for top-level icons?
Could I reproduce this issue with the Puppy 4.2 alpha2
No, Sigmund. I had corrected the problem (I don't know how) before I uploaded alpha2. Alpha3 is now up and working without that issue, but needs to have the pweather font corrected and the clock-click fix implemented properly. Please check my implementation to see why it doesn't work in Alpha3. Thanks, mate.

Posted: Wed 04 Feb 2009, 19:46
by HairyWill
Sigmund
I agree that editing all the desktop files and repackaging the pets is a lot of work I don't we should be aiming to do it in a rush. It would be good if pet packagers were made aware of the benefits of a fully completely definition. At the moment the benefits are small because there are few tools which use the information. The xdg menu systems support for internationalisation is the only one I can think of. Also this really is a problem that should be solved at the level of the pet creator rather than requiring someone else to repackage the pet.

It might be helpful to put some changes into dir2pet that would help to build more complete .desktop files.

Another interesting project would be to build an online pet checker that could check a package for common problems and levels of conformance with existing versions of puppy. This could do things like identify any existing files that would be overwritten and check that the icons specified exist. By using the md5 hash attached to the pet as a GUID it would possible to build an online system for tracking pets and obtaining/submitting information about them. It is a massive project and I am starting to digress so I will stop.

Posted: Wed 04 Feb 2009, 20:30
by rarsa
zigbert wrote:Why I don't use the icons in the .desktop files is simply because they point to a 16x16 pixel icon instead of a 48x48.
Actually this is currently the case but it does not have to be this way. When I implemented the XDG specification I did it in a way that would fit Puppy at the time.

The full and most current Desktop entry specification has two provisions regarding the icon parameter. Here is the explanation for the icon field:
Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be used. If the name is not an absolute path, the algorithm described in the Icon Theme Specification will be used to locate the icon.
The current code only considers full path but I can certainly improve the code to add more functionality. I haven't been following all the threads so I have no clue what you mean about globicons, I'd appreciate a PM with a quick explanation.

I would prefer to do it the standard way and fix it instead of finding workarounds creating our own custom Puppy files.
HairyWill wrote:Maybe it would be sensible for puppy to move to applications supplying more complete .desktop files (containing translations as well).
The first round of .desktop files were created by script, Extracting information from the (then current), puppy JWM menu. The intention was to improve on those .desktop files.

One of the problems I found at the time was that developers were providing .desktop files that weren't properly categorized. Barry also did tweak the categories to fit his menu structure.

As you mentioned in other post, any cleanup of the .desktop files can be done by script, so it's not that much work. (Been there, done that ;) ). I have some scripts that do the following:

Get all the .desktop files from all the Unleashed packages
Do some modification
Repackage the new desktop file into the unleashed packages

Posted: Mon 18 May 2009, 03:32
by ecomoney
For those (unlike me) that are gifted with artistic talent....

We need a good theme for Puppy 5 "Woof"! Suggestions are invited here