Re: [PATCH v3] wmaker: Consistent configuration options.
On Wed, 22 Mar 2017, Carlos R. Mafra wrote: On Wed, 22 Mar 2017 at 11:44:20 +0100, BALATON Zoltan wrote: On Wed, 22 Mar 2017, Doug Torrance wrote: Some of the paths in IconPath and PixmapPath have been removed. In particular, the various system pixmap paths (/usr/include/X11/pixmaps, /usr/share/pixmaps, and /usr/local/share/pixmaps) have been removed in favor of PIXMAPDIR, which is specified by the user at build. Also, /usr/share/icons has been removed from IconPath. The root of this directory will contain very few icons, as the icons themselves are located in subdirectories corresponding to XDG icon themes. I don't think this is a good idea because then it's not possible to specify icon paths at runtime. Compile time option is less flexible and only allows to set one value so I think these options should be kept. (Otherwise some users will see missing icons after upgrade as well.) I don't think that will be the case. By default wmaker.inst does not overwrite user's config files at installation time. OK, then I think I've misunderstood the patch. If these options are still working and taken from the user's config just some defaults have been removed for new installations then no problem with it. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH v3] wmaker: Consistent configuration options.
On Wed, 22 Mar 2017, Doug Torrance wrote: Some of the paths in IconPath and PixmapPath have been removed. In particular, the various system pixmap paths (/usr/include/X11/pixmaps, /usr/share/pixmaps, and /usr/local/share/pixmaps) have been removed in favor of PIXMAPDIR, which is specified by the user at build. Also, /usr/share/icons has been removed from IconPath. The root of this directory will contain very few icons, as the icons themselves are located in subdirectories corresponding to XDG icon themes. I don't think this is a good idea because then it's not possible to specify icon paths at runtime. Compile time option is less flexible and only allows to set one value so I think these options should be kept. (Otherwise some users will see missing icons after upgrade as well.) Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] In the README it is said to run ./configure but there's no such script in the tarball. I wrote instructions to generate a ./configure with libtool and autotools.
On Tue, 6 Oct 2015, Shining wrote: On Tue, 6 Oct 2015 17:27:30 +0300 "Alexey I. Froloff" <ra...@raorn.name> wrote: On Mon, Oct 05, 2015 at 11:19:42PM +0200, Shining wrote: +libtoolize +aclocal +autoconf +automake --add-missing "autoreconf" command should be enough. No, it doesn't: What about "autoreconf -if"? I think that should work but haven't tried. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
On Sat, 22 Aug 2015, Josip Deanovic wrote: On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: Which feature was removed that you are missing? The one I am talking for over a year now. :-) Also app icon caching was broken around the same time. The app icon cache in CachedPixmaps was meant to store icons retrieved from X clients so the dock or clip can display those when the client is not running like after startup. The cache should contain only such icons and the path should never appear in WMWindowAttributes because the cache is an internal thing used to look up icons not otherwise available. If you look at your WMWindowAttributes now it is full of entries referring to the cache that should not be there and if you look at the cache dir you'll find a lot of icons from all apps you've ever started while there should be only the few docked ones that use client side icons. Also the cache is never cleaned up only new icons are added to it. The icon handling code was a bit complicated before but worked (maybe cache cleanup was broken before) until overzealous simplification attempts have messed it up so much that it is now difficult to untangle. Even more so because the object oriented design was also messed up by renaming and moving methods around so now it is not clear what object methods these functions were meant to be. I think the principles to follow should be: 1. K.I.S.S. 2. If ain't broke don't fix it. 3. If you don't understand it don't touch it. (That is, think about all possible implications of your proposed change because it may work with your particular settings but a lot of things can be set by preferences.) Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
home page version number
Hello, On the windowmaker.org home page at the Download on the bottom it still says 0.95.6 although it links to a 0.95.7 tar.gz. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] make it possible to rename workspaces from Workspace Menu
On Mon, 27 Jul 2015, Amadeusz Sławiński wrote: useful when there is no clip around It's already possible to do this by Ctrl+clicking the menu item. (You can even rename other than the current workspace with that.) Do we need another menu item for it? Regards, BALATON Zoltan
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Tue, 23 Jun 2015, Josip Deanovic wrote: Sorry, my mistake. Its No application icon option, not Shared application icon. I have just retested it. Ah, ok, that makes sense. If an app is set to not have an app icon it cannot be attached to the dock so when you start it the instance will not have an app icon so the docked one is not linked to the running instance. Hence clicking on it again may start a new instance. This is kind of consistent even if quite unintuitive. I have even used got bisect to find which patch changed the behavior. Did you find the patch that changed it? Or is this behaviour still there? Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Mon, 22 Jun 2015, Josip Deanovic wrote: My conclusion here is that the docked appicon still acts as an appicon which is not intuitive but its probably correct from the windowmaker design (look and feel) perspective. In my opinion it is more intuitive than having a docked appicon behave differrently. The dock is really just a place to attach appicons to, they are still appicons. This is how it was working in *step and how it still works on OS X. Windowmaker up until and including 0.95.3 would allow subsequent double clicks on the docked appicon to start new instances of the application which was probably incorrect from the windowmaker design (look and feel) perspective but some people learned to use that feature. I've never seen this behaviour but maybe I've skipped the buggy versions that had this feature or used settings where this didn't happen. Double click raised app windows and Ctrl+DblClick started another instance whenever I've tried. The ability to use Ctrl+DblClick on undocked appicons was added recently, previously it only worked on the dock/clip. Instead, I would like to propose a new option under the Application Specific options, in the application attributes winow which would: - make docked appicon behave more like an launcher for the application instead of the application's instance appicon - allow double click and subsequent double clicks on the docked appicon to launch new instances of the application Users would then be able to drag an appicon to the dock and configure the window attributes in a way that the docked appicon doesn't ack as a docked appicon but as a launcher which would be much more intuitive taking into account the year we live in. :-) Window attributes are app specific. This setting seems to be a dock/clip option so maybe it should be a pref setting for dock/clip instead. A window attribute does not make much sense here unless you want it selectively for different apps, but that's really bad ergonomics as that would be very confusing if icons for different apps would behave differently when docked. So this looks more like a dock feature to me to have click on running appicon start new instance more like a launcher. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Is anybody building rpms from wmaker-crm/next?
On May 27, 2015 5:55 AM, Martin Dietze mdie...@gmail.com wrote: As far as I understand the very idea behind SuSE's Open Build Service (http://en.wikipedia.org/wiki/Open_Build_Service) is to provide an infrastructure to provide native packages for different distros. This does not free maintainers from making the necessary changes in their specs, and of course this tends to uglify specs. Still I believe that doing this would be a great benefit for the community. Why trying to package next for all distros? It is a development branch. Distros are usually already packaging the relesed versions of Window Maker. Maybe the problem is that Window Maker is not released very often so the distro package most likely will be an older version. It takes some time for a distro to catch up but it's the best way to make sure the package is integrated in the distro and will work without problems. Otherwise we would need to provide third party repos for each distro and follow their development. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
if they have references to visuals, gcs, fonts, etc. It may work on screens that have the same visuals which might be common now but removing support for more complex setups is breaking previous functionality that's already there and not really correct in X which allows this to exist. Or maybe I'm missing something because I did not check the code, just talking at a higher design level. But I remember I needed to revert some of your previous changes which seemed OK at first but turned out it broke displays with multiple screens because removing screen references from objects made them display on multiple screens and mix up things like icons attached to one clip showing up on another screen and so on. Are you sure it's not more complex than you think and you've considered all scenarios and not trying to build on overly simpified assumptions? Regards, BALATON Zoltan
Re: Wayland support?
On Tue, 17 Feb 2015, Rodolfo García Peñas (kix) wrote: thanks a lot for your reply. I will try to reply you later again, with more info. No need to hurry, I have no time to look at it or work on Window Maker so I could only share my thoughts in the hope it might help. What you propose is probably similar to gtk where there is a creation phase and a realize phase. I'm still wondering if the added complexity of splitting to abstract objects and window system specific ones worth it? What does it bring apart from more complex code? (OK we could be window system independent but I don't think we really need that in a Window Manager for X.) Shouldn't the split be done in the initialization functions instead to make object creation and tying it to a screen separate actions? I mean couldn't the same be achieved by having a way to unmap and disassociate an object from a WScreen and add it to another? Isn't this enough to achieve screen independent objects that could be moved to another screen? Could this be implemented by two new methods on existing objects instead of introducing a new abstraction layer inbetween for everything? Some of this may already exist but probably it's part of creating the objects now so the only think needed would be to split it off into another method. (Although some objects like pixmaps need to be created on a screen so moving them to another screen would mean effectively destroying and recreating them so this independence only makes sense for higher level objects like windows but not for lower level ones like decorations.) Another comment unrelated to this but reminded by your message mentioning WScreen and virtual_screen: I'm also not a big fan of partially renaming functions and breaking any conventions and creating a mess of mixed conventions in the same code. I mean previously the naming convention was similar to OpenStep but being pure C the objects were denoted by their names only: e.g. WScreen for object with object methods named wScreen*. (functions start with lower case while object types start with capital letter). Other funtions not being object methods were usually just named someFunctionName. (This was not always followed but one could more or less tell the idea and intended object separation by looking at the names.) Then someone decided for no good reason other than personal preference that CamelCase is evil and better use underscore names instead like gtk for example. This could be OK if there was a mass renaming and folowing some convention because even in gtk there's a common prefix for all object member functions and names are not just invented randomly. If the renaming has been done object by object keeping some logic to show the object relations it would have been acceptable but what is happening now is that the object oriented design starts to disappear with names becoming a random mix of CamelCase and underscore_separated without following any convention. I have no strong feelings for any of the conventions but I'd prefer to keep some consistency and follow one or the other but not mix them and keeping one convention at least within one object. So unless a whole object is converted to underscore names keeping its naming consistent, it's better to keep the previous naming convention. It also can be considered to keep the CamelCase names for objects and only rename non-object functions to underscore names to have a clear separation of objects and other helper functions or any other sensible approach other than messing up naming by partially renaming some functions while keeping others until noone can see what functions were meant to be members of which objects. Keeping the object oriented design also helps with keeping separation between objects and to know their relations. It makes it simpler to know what is handled by which set of functions and while there is no language support for it in C one can still keep this separation and not mess up by accessing another object's data from a foreign one but use approprite member functions for that. This takes some discipline and is already broken in a few places but it would be better if new patches would keep or fix this design rather than messing it up further. Regards, BALATON Zoltan
Re: [PATCH] wmaker: Restore multi screen functionality by reverting wrong commits
On Thu, 6 Nov 2014, Rodolfo García Peñas (kix) wrote: please, how can I reproduce the problem? - attach appicons to the dock and clip - connect a second display and configure X to handle them as separate screens (such as display :0.0 and :0.1) The screens in this config are separate (and may have different visual settings too) so it is not possible to share a single WScreen between them as that causes mixup of objects on separate screens. Regards, BALATON Zoltan
xpdf appicon
Hello, I'm seeing a problem with the appicon of Xpdf that it remains on screen after the app has exited and cannot be made to go away without restarting Window Maker. I did not see this happen to any other application so I think it is due to some strange behaviour of Xpdf itself but this did not happen in previous Window Maker versions so it could cope with it before. Now it seems to happen when Xpdf is not in any dock, then when started an app icon appears but it stays there without the app when I quit Xpdf. Does anyone see this same problem and maybe have an idea for a fix? Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: appicon icons
Hello, On Tue, 21 Oct 2014, Yury Tarasievich wrote: I think I know now how to reproduce the appicon icon not being set and left as the default broken sphere. For this to happen you have to have no dock and no clip. Appicons (sort of) are created anyway, for active apps only, but the icons for them aren't extracted/requested from app or whatever. If application is active while dock is activated and windowmaker restarted, then this sort-of-appicon gets its correct icon from app, and then you may switch the dock off, and the correct icon is retained through all subsequent restarts of the app. So it's just the dock being active (clip, too, possibly) that enables the appicon icon setting. Could somebody look into this? Should be trivial. Might not be trivial to find due to the number of changes that went into icon handling in the past... I think app icon caching was broken by some of these cleanups to icon code and since then: - all icons are cached - WMWindowAttributes is polluted with entries pointing to cache - icons are sometimes replaced when starting the app (seen this for java apps) I think these might be related but would require someone to go through the icon code and understand all changes to find the bad ones. It's not something I volunteer to do... Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: application menus not working on dual screen
On Wed, 22 Oct 2014, Christian wrote: running latest WindowMaker (0.95.6) and having a strange problem. I am using a two monitors (2x 27(1920x1080) - 3840x1080). On some applications the app specific menu does not work. You can click on the menu, but nothing is shown. What is app specific menu? Any ideas what this could be ? Does the latest version in git HEAD still have this problem? (I've submitted a big revert patch that might fix this too as it moved back menus to screens as well but I don't know if it's relevant to Xinerama displays where you should have a single screen.) Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: application menus not working on dual screen
On Wed, 22 Oct 2014, BALATON Zoltan wrote: Does the latest version in git HEAD still have this problem? (I've submitted a big revert patch that might fix this too as it moved back menus to screens as well but I don't know if it's relevant to Xinerama displays where you should have a single screen.) Forgot to say that it is in next branch in case you don't know about it. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH] wmaker: Restore multi screen functionality by reverting wrong commits
Revert patches that moved variables from WMScreen to global level
because this broke X displays with multiple independent screens and
caused dock and clip icons to become mixed up. When managing multiple
screens each screen used to have it's own state/dock and clip. This
commit restores that by reverting mainly the commits listed below (and
those that are invalidated by reverting these) and fixing up later
commits to apply after the revert.
Reverted commits:
f60e65001bfdd21fd9939b2b0121037682b6522c Moved 'workspace_name_font' from the
Screen to a Workspace object in the global namespace
9e103a46e99d323e070c3779c5d261c171df2e17 Variable workspace_count moved to the
workspace object in the global namespace
e5ae684d02fdb66f1a90d486a21fd70498464f90 Variable last_workspace moved to
workspace object in global namespace
c610b8d7ce865938a7a5e2aa97772f2a67f30602 Variable current_workspace moved to
workspace object in global namespace
f0c50736001dd8c5a81ab1ae5926f6e14b7a9730 Array of workspaces moved to the
workspace object in the global namespace
9c252988f8378876b9710561428666799317673c Variable workspace_menu moved to
workspace object in global namespace
e86b8dcb2f28bf06ff04e12ea15754b684437f31 Clip, Dock and Drawers menu moved to
appropriate global namespace
074092f319706bfe3f4df8873aab962ece25e9c3 Removed WScreen args not used
4a7daf2322901ca43b5cea2cab26015394db5b95 AppIcon list moved out of WScreen
2103fe390b839c2eea6a288539c5bd1c43435ac7 Variable clip_icon moved to clip
object in the global namespace
014bc52531ec5d554920ce82d3e1046e26f84a3b wClipIconPaint appicon argument removed
40e1ea08b86a9d77488f451588581bacb794fdb2 Varible session_state moved to global
namespace
6987d4aa4041f17f31e05d677326b42b01f946de Removed WScreen argument
0de3e590cedeb441d7c5038b8fae26bf851c5fd8 shortcutWindows moved to w_global
2e64831fb6742d8fc4164000da9acae4738853a8 Removed unused variable wapp_list
b6423a7b4f0111f73690d2a99ca0433d30b5dd32 wmaker: Moved variable Screen Count
into the global namespace
---
src/WindowMaker.h | 52 ++--
src/actions.c | 56 ++---
src/appicon.c | 60 ++---
src/application.c | 17 +++-
src/balloon.c | 6 +-
src/cycling.c | 2 +-
src/defaults.c| 32 +++
src/defaults.h| 2 +-
src/dock.c| 198 ++-
src/dock.h| 6 +-
src/dockedapp.c | 4 +-
src/event.c | 59 ++---
src/main.c| 2 +-
src/menu.c| 13 +--
src/misc.c| 2 +-
src/moveres.c | 40 -
src/placement.c | 6 +-
src/rootmenu.c| 12 +--
src/screen.c | 37 -
src/screen.h | 29 +++
src/session.c | 67 ---
src/session.h | 2 +-
src/startup.c | 12 +--
src/switchmenu.c | 6 +-
src/switchpanel.c | 2 +-
src/wdefaults.c | 4 +-
src/window.c | 63 +++---
src/winmenu.c | 65 ---
src/winspector.c | 17 ++--
src/wmspec.c | 36
src/workspace.c | 245 +++---
src/workspace.h | 6 +-
src/xdnd.c| 2 +-
33 files changed, 589 insertions(+), 573 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 92e1ba6..82188bd 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -511,43 +511,12 @@ extern struct wmaker_global_variables {
/* Screens related */
int screen_count;
- /* Workspace related */
- struct {
- struct WWorkspace **array; /* data for the workspaces */
-
- int count; /* number of workspaces */
- int current;/* current workspace number */
- int last_used; /* last used workspace number */
-
- WMFont *font_for_name; /* used during workspace switch */
-
- /*
-* Ignore Workspace Change:
-* this variable is used to prevent workspace switch while
certain
-* operations are ongoing.
-*/
- Bool ignore_change;
-
- /* Menus */
- struct WMenu *menu; /* workspace operation */
- struct WMenu *submenu; /* workspace list for window_menu */
- } workspace;
-
- /* Clip related */
- struct {
- struct WAppIcon *icon; /* The clip main icon, or the dock's,
if they are merged */
-
- struct WMenu *menu; /* Menu for clips */
- struct WMenu *submenu; /* Workspace list for clips */
- struct WMenu *opt_menu; /* Options for Clip */
- struct WMenu *ws_menu; /* workspace menu for clip */
- } clip;
-
- /* Dock related */
- struct {
- struct WMenu *pos_menu; /* menu for position of the dock */
- struct WMenu *drawer_menu; /* menu for the drawers */
- } dock;
+ /*
+* Ignore
Re: multi screen support
Hello, Looks like an interactive rebase from the start of the commits in question and some fixing up of the later patches made it relatively easy to revert the changes. I've sent a patch which restores previous state and reverts commits that broke multi screen support. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Segfault with pango support
Hello, Tried the new Pango support but it segfaulted while starting Window Maker. Here are the backtraces: #0 0x7f57cac7caea in __strcmp_sse42 () from /lib64/libc.so.6 #1 0x7f57cdd7c7b0 in WMWidthOfString (font=0x12a92d0, text= 0x12e87c0 Keep on Top, length=optimized out) at ../../wmaker-crm/WINGs/wfont.c:296 #2 0x00433b16 in wMenuRealize (menu=0x12e80f0) at ../../wmaker-crm/src/menu.c:503 #3 0x00433c63 in wMenuRealize (menu=0x12e7c80) at ../../wmaker-crm/src/menu.c:476 #4 0x00421b13 in makeClipOptionsMenu (scr=0x1252300) at ../../wmaker-crm/src/dock.c:1077 #5 dockMenuCreate (type=1, scr=0x1252300) at ../../wmaker-crm/src/dock.c:1237 #6 wDockCreate (scr=scr@entry=0x1252300, type=type@entry=1, name=name@entry= 0x0) at ../../wmaker-crm/src/dock.c:1352 #7 0x00461b9f in wWorkspaceNew (scr=scr@entry=0x1252300) at ../../wmaker-crm/src/workspace.c:108 #8 0x0044562d in wScreenInit (screen_number=0) at ../../wmaker-crm/src/screen.c:637 #9 0x0044a9ed in StartUp (defaultScreenOnly=optimized out) at ../../wmaker-crm/src/startup.c:636 #10 0x0040acdc in real_main (argv=optimized out, argc=2) at ../../wmaker-crm/src/main.c:778 #11 main (argc=2, argv=optimized out) at ../../wmaker-crm/src/main.c:587 then the monitor instance also segfaulted while trying to display a crash dialog: #0 0x7f7d889a0aea in __strcmp_sse42 () from /lib64/libc.so.6 #1 0x7f7d8baa07b0 in WMWidthOfString (font=font@entry=0x1141520, text=text@entry=0x1189900 OK, length=optimized out) at ../../wmaker-crm/WINGs/wfont.c:296 #2 0x7f7d8baa6650 in fitText (text=text@entry=0x1189900 OK, font=font@entry=0x1141520, width=width@entry=46, wrap=wrap@entry=1) at ../../wmaker-crm/WINGs/wmisc.c:108 #3 0x7f7d8baa6dac in W_GetTextHeight (font=font@entry=0x1141520, text=text@entry=0x1189900 OK, width=width@entry=46, wrap=wrap@entry=1) at ../../wmaker-crm/WINGs/wmisc.c:153 #4 0x7f7d8baa71d7 in W_PaintTextAndImage (view=0x1189730, wrap=1, textColor=0x112d680, font=0x1141520, relief=WRRaised, text=0x1189900 OK, alignment=WACenter, image=0x117f760, position=WIPRight, backColor=0x0, ofs= 0) at ../../wmaker-crm/WINGs/wmisc.c:304 #5 0x7f7d8ba92f07 in paintButton (bPtr=optimized out) at ../../wmaker-crm/WINGs/wbutton.c:594 #6 0x7f7d8ba9d94c in WMHandleEvent (event=event@entry=0x7fff672c4230) at ../../wmaker-crm/WINGs/wevent.c:273 #7 0x0041f057 in wShowCrashingDialogPanel (whatSig=whatSig@entry=11) at ../../wmaker-crm/src/dialog.c:1676 #8 0x00438a83 in showCrashDialog (sig=11) at ../../wmaker-crm/src/monitor.c:52 #9 MonitorLoop (argc=optimized out, argv=argv@entry=0x7fff672c45a8) Since font and text are checked for not being NULL may it be that pango_layout_get_text returns NULL and that makes it crash? Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Fullscreen apps and dock
On Fri, 17 Oct 2014, Torrance, Douglas wrote: If you right click on the dock and go to Dock position, what is the selection? Selecting Keep on Top will produce the behavior you described. The question may be if it should behave like that or not. When looking for patches that broke multiple screens I've also seen a change which removed FullScreen Window level. Not sure if this is related but someone trying to fix this might want to search for that in history and check what has been changed. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
multi screen support
Hello, I've tried using Window Maker from git next with multiple screens and it seems changes made about a year ago broke this. (Under multiple screens I mean when X is configured to have a display with separate screens for each head, thus I have :0.0 and :0.1 as opposed to Xinerama or nvidia TwinView which combines multiple monitors into a large display.) The patches that broke this are roughly between: 4ac65ab260ebbbec26f8f77e3620835b5a3b..b7ae1b50e28ebc2a4d16f28ea51779c9380d66d6 which incorrectly moved some screen specific data to the global level. As a result the app icons attached to the first screen's clip appear on the second screen now while previously each screen had a separate dock and clip. (Probably other icons are mixed up too but not as visible as with the clip.) Can the above changes be reverted (and is there an easy way to do this) to restore support for multiple screen displays? Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014, BALATON Zoltan wrote: I remember there used to be an option called something like Windoze cycling in expert prefs but I can't find it any more. Maybe it was removed previously in one of the clean up patches. I've tried to find it in history but could not, maybe you have better luck finding it. Looks like the setting is still there in WindowMaker.h, struct Wpreferences as member named windows_cycling but reading it from config was removed from defaults.c. I could not find it actually used as far back as 0.91.0 so it may have been removed before that. This setting was exactly for changing the behaviour of Mod-Tab switching between cycling through windows vs. bringing the last focused window to the top of the list. You may want to look at reviving this. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/5] wmaker: fix focused window list order
On Sat, 20 Sep 2014, Carlos R. Mafra wrote: On Sat, 20 Sep 2014 at 11:51:06 +0200, Amadeusz Sławiński wrote: On Sat, 20 Sep 2014 17:04:02 +0800 David Maciejak david.macie...@gmail.com wrote: That is the behaviour i have without the patch (and that's why i called it mixed up windows list): 1 has focus alt-tab (next window) show 1 [2] 3 2 has focus alt-tab show 2 [1] 3 1 has focus alt-tab show 1 [2] 3 press another alt-tab, select 3 1 2 [3] 3 has focus alt-tab show 3 [1] 2 another alt-tab to 2, show 3 1 [2] 2 has focus alt-tab show 2 [3] 1 To do that i just configured the Focus next window in WPrefs to alt-tab. But as said that behaviour is sounding more like move focus back to previous focused window. A, B, [C], D now I alt-tab again and with this patch it goes to D A, B, C, [D] yes that was what i was expecting from Focus next window [A], B, C, D I 'alt-tab' and while keeping alt down, I 'tab' more and end up on let's say C A, B, [C], D with old behaviour I am back on A [A], B, C, D That's focus on previous focused window. I can understand that feature is useful but not really expected. I've checked some other operating systems and OS X and Windows XP (both using switchpanels) bring application you change to, to the front of the window list. I would say it makes a lot of sense in keyboard driven windows management. People usually work with few applications and want to change between them instantly, without going through a whole list (especially if they have a lot of windows open), so it makes a lot of sense to keep recently used ones closer on list. Imagine for example: webbrowser, xterm, xterm, xterm, mailapp, xterm, xterm, xterm, xterm with task being: copying stuff from webbrowser to mailapp. With your patch you would need each time focus on where your browser and mailapp are and go through all those xterms when changing windows, instead of instantly changing between them. Precisely! What David wants to fix is actually more of a semantic problem. In practice, the current behaviour is much more desirable for the reason you pointed out. And quite frankly, we cannot change such a behaviour right now. Long-time wmaker users will just be annoyed, and they are wmaker's biggest asset. But yes, I've checked and I confirm that it doesn't work too well with mouse bindings (Next Window keeps changing just between two windows, instead of going through list) which, as I understand is the way you want to use it. I think the way out is to introduce an option to select between David's and the current behaviour. Something along the lines of Strict focus next behaviour with default off and many comments about it being useful for the mouse bindings (perhaps in balloon texts). I remember there used to be an option called something like Windoze cycling in expert prefs but I can't find it any more. Maybe it was removed previously in one of the clean up patches. I've tried to find it in history but could not, maybe you have better luck finding it. Regards, BALATON Zoltan
Re: [PATCH] Test to remove code
Hello, On Mon, 25 Aug 2014, Rodolfo García Peñas (kix) wrote: Probably, the old idea was show the icon in the minimized icon list and then move the icon to the Dock/Clip/Drawer possition for that icon. I don't know what the original idea was but on OPENSTEP when an app is launched (usually by clicking an icon in the file manager) the icon is visually moved to the appicon which represents the running instance. Maybe this was the original idea. In Window Maker I've seen such animations for apps with shared app icons and it helps to show you that the app you've started has become a member of that shared group. I'm not sure these are related to your proposed patch but may be. Regards, BALATON Zoltan
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Mon, 9 Jun 2014, Yury Tarasievich wrote: Personally, I wouldn't mind the change of this behaviour, anyway. Right now the icon of the app already launched does nothing useful on single/double click and just takes up the screen space. For launched apps it brings the app forward or acts as a place holder for the hidden app and unhides it (and also opens the app menu on right click where you can do actions like kill a frozen app, etc.). This is what all app icons do (regardless if docked or not). If some would launch additional instances instead that would be inconsistent. Launching with Ctrl is an additional function not clashing with the primary function. I think they cannot do both at the same time in a consistent way. You said when it worked the way you described it only launched additional instances of apps with some setting but behaved like other appicons for others if I got that correctly. This does not sound more consistent than the current behaviour to me so I don't think it should be a default option. That, or completely do without the icons' strips of any kind. Optionally, if you please. You can already switch off the Dock and the Clip, why not dispense with the icons completely? You can disable appicons per app already and you could add a default to disable it for all apps. (I did not try it but it may work.) In the window inspector (that you can bring up selecting Attributes in a Window menu) select Defaults for all windows in the Window Specification tab then No application icon on Applicaion Specific tab. If Window Maker becomes unusable as a result you can revert it by deleting the appropriate section from your GNUstep/Defaults/WMWindowAttributes. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH dockapps 10/28] wmix: fixed makefile to use PREFIX in a standard way (and with the standard default path)
On Sat, 7 Jun 2014, Christophe wrote: From: Christophe CURIS christophe.cu...@free.fr Signed-off-by: Christophe CURIS christophe.cu...@free.fr --- wmix/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/wmix/Makefile b/wmix/Makefile index 3ef4f3a..ffc1d5f 100644 --- a/wmix/Makefile +++ b/wmix/Makefile @@ -5,8 +5,7 @@ LIBS= -lXpm -lXext -lX11 -lm OBJECTS = misc.o mixer-oss.o ui_x.o wmix.o # where to install this program (also for packaging stuff) -DESTDIR= -PREFIX = $(DESTDIR)/usr/X11R6 DESTDIR is usually there so that distributions can install stuff in a build root during packaging like this: build with PREFIX=/usr/X11R6 make install DESTDIR=/tmp/build-root Does your change break this or is there another way to do the same? (If PREFIX is not compiled in the program but only used for installing stuff it may be OK.) Regards, BALATON Zoltan +PREFIX = /usr/local INSTALL_BIN = -m 755 INSTALL_DATA= -m 644 -- 1.9.2 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Sat, 7 Jun 2014, Josip Deanovic wrote: Starting with version 0.95.4 Windowmaker doesn't behave the same way any more and it is not possible to execute multiple instances of a docked application using double-click. It is still possible to execute additional instances of the application in the wmdock using right-click and then selecting Launch from the menu but this is not practical at all in every day use. I suggest restoration of the behavior from pre-0.95.4 version I don't mind either way (not using that option) but isn't double click with Ctrl pressed sufficient to launch another instance? Double click brings forward the running application and if it behaved differently for some applications it would be inconsistent. BTW, what is the meaning of the Shared application icon option in the Application Specific Attributes window? It's what it says, that multiple instances of one application will share a single icon. For example you can have a single icon for all terminal windows so you can hide them at once. (Actually on *step the icons belong to applications which can have multiple windows. So these windows all belong to a single application and thus icon. This can be emulated by the shared application icon when the windows are separate instances of an X application.) Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Double-click on application in wmdock does not launch the application if one instance is already running
On Thu, 5 Jun 2014, Josip Deanovic wrote: As said in the subject, double-click on an application in wmdock does not launch the application in case there is an instance of the application already running. As I heard from a friend of mine it used to work in 0.95.3 and previous versions of Windowmaker with Shared application icon check box turned on for a specific application that has been added to wmdock. With version 0.95.5 and version from current git repository it is not the case any more. It is possible to launch additional instance by using right-click and selecting Launch option but this really sucks. Is this behavior intentional? I don't think it ever worked the way you describe or if it did it was probably a bug. What used to work and should still work is starting additional instances with Ctrl+double click. So I think this is intentional and not a regression. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WPrefs: add expert option to disable switch panel
On Wed, 4 Jun 2014, Iain Patterson wrote: * Decide whether to call it the switchpanel or the switch panel (I vote the former since it's most prevalent. I agree with your suggestions mostly but switchpanel is not really an English word and to me looks like a typo so I wonder if one of the other options would be better even if that needs changing at more places. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 0/2] Patches rebased on next
Hello, I'm sending my two not yet merged patches rebased to the next branch. Regards, BALATON Zoltan --- BALATON Zoltan (2): WPrefs: Make Dock preferences pane less busy and fix up some strings Updated Hungarian translation WINGs/po/hu.po | 213 +--- WPrefs.app/Configurations.c | 6 +- WPrefs.app/Docks.c | 36 +--- WPrefs.app/Focus.c | 2 +- WPrefs.app/WindowHandling.c | 6 +- WPrefs.app/Workspace.c | 4 +- WPrefs.app/po/hu.po | 171 +-- po/hu.po| 8 +- 8 files changed, 203 insertions(+), 243 deletions(-) -- 1.8.1.5 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 1/2] WPrefs: Make Dock preferences pane less busy and fix up some strings
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu
---
WPrefs.app/Configurations.c | 6 +++---
WPrefs.app/Docks.c | 36 +---
WPrefs.app/Focus.c | 2 +-
WPrefs.app/WindowHandling.c | 6 +++---
WPrefs.app/Workspace.c | 4 ++--
5 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/WPrefs.app/Configurations.c b/WPrefs.app/Configurations.c
index 4fdc777..34b716d 100644
--- a/WPrefs.app/Configurations.c
+++ b/WPrefs.app/Configurations.c
@@ -204,9 +204,6 @@ static void createPanel(Panel *p)
WMResizeWidget(panel-smoF, 94, 100);
WMMoveWidget(panel-smoF, 420, 10);
WMSetFrameTitle(panel-smoF, _(Smooth Scaling));
- WMSetBalloonTextForView(_(Smooth scaled background images,
neutralizing\n
- the `pixelization' effect. This will slow\n
- down loading of background images
considerably.), WMWidgetView(panel-smoF));
panel-smoB = WMCreateButton(panel-smoF, WBTToggle);
WMResizeWidget(panel-smoB, 64, 64);
@@ -237,6 +234,9 @@ static void createPanel(Panel *p)
RReleaseImage(image);
}
+ WMSetBalloonTextForView(_(Smooth scaled background images,
neutralizing\n
+ the `pixelization' effect. This will slow\n
+ down loading of background images
considerably.), WMWidgetView(panel-smoB));
WMMapSubwidgets(panel-smoF);
diff --git a/WPrefs.app/Docks.c b/WPrefs.app/Docks.c
index e85f5df..7d54f30 100644
--- a/WPrefs.app/Docks.c
+++ b/WPrefs.app/Docks.c
@@ -36,6 +36,7 @@ typedef struct _Panel {
WMLabel *autoDelayL[4];
WMButton *autoDelayB[4][5];
WMTextField *autoDelayT[4];
+ WMLabel *autoDelayMsL[4];
WMFrame *dockF;
WMButton *docksB[3];
@@ -51,10 +52,10 @@ static const struct {
const char *key;
const char *string;
} auto_delay[] = {
- { ClipAutoexpandDelay, N_(Delay before auto-expansion) },
- { ClipAutocollapseDelay, N_(Delay before auto-collapsing) },
- { ClipAutoraiseDelay,N_(Delay before auto-raise) },
- { ClipAutolowerDelay,N_(Delay before auto-lowering) }
+ { ClipAutoexpandDelay, N_(Before auto-expansion) },
+ { ClipAutocollapseDelay, N_(Before auto-collapsing) },
+ { ClipAutoraiseDelay,N_(Before auto-raise) },
+ { ClipAutolowerDelay,N_(Before auto-lowering) }
};
@@ -149,6 +150,8 @@ static void createPanel(Panel *p)
char *path;
int i, j, k;
char *buf1, *buf2;
+ WMColor *color;
+ WMFont *font;
path = LocateImage(ARQUIVO_XIS);
if (path) {
@@ -172,23 +175,23 @@ static void createPanel(Panel *p)
WMResizeWidget(panel-autoDelayF[k], 370, 100);
WMMoveWidget(panel-autoDelayF[k], 15, 10 + k * 110);
if (k == 0)
- WMSetFrameTitle(panel-autoDelayF[k], _(Delays in
milliseconds for autocollapsing clips));
+ WMSetFrameTitle(panel-autoDelayF[k], _(Clip
autocollapsing delays));
else
- WMSetFrameTitle(panel-autoDelayF[k], _(Delays in
milliseconds for autoraising clips));
+ WMSetFrameTitle(panel-autoDelayF[k], _(Clip
autoraising delays));
for (i = 0; i 2; i++)
{
panel-autoDelayL[i + k * 2] =
WMCreateLabel(panel-autoDelayF[k]);
- WMResizeWidget(panel-autoDelayL[i + k * 2], 175, 20);
+ WMResizeWidget(panel-autoDelayL[i + k * 2], 155, 20);
WMMoveWidget(panel-autoDelayL[i + k * 2], 10, 27 + 40
* i);
WMSetLabelText(panel-autoDelayL[i + k * 2],
_(auto_delay[i + k * 2].string));
- WMSetLabelTextAlignment(panel-autoDelayL[i + k * 2],
WARight);
+ /* WMSetLabelTextAlignment(panel-autoDelayL[i + k *
2], WARight); */
for (j = 0; j 5; j++)
{
panel-autoDelayB[i + k * 2][j] =
WMCreateCustomButton(panel-autoDelayF[k], WBBStateChangeMask);
WMResizeWidget(panel-autoDelayB[i + k * 2][j],
25, 25);
- WMMoveWidget(panel-autoDelayB[i + k * 2][j],
185 + (25 * j), 25 + 40 * i);
+ WMMoveWidget(panel-autoDelayB[i + k * 2][j],
145 + (28 * j), 25 + 40 * i);
WMSetButtonBordered(panel-autoDelayB[i + k *
2][j], False);
WMSetButtonImagePosition(panel-autoDelayB[i +
k * 2][j], WIPImageOnly);
WMSetButtonAction(panel-autoDelayB[i + k *
2][j], pushAutoDelayButton, panel);
@@ -213,9 +216,20 @@ static void createPanel(Panel *p)
}
panel
[PATCH 2/2] Updated Hungarian translation
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu --- WINGs/po/hu.po | 213 +--- WPrefs.app/po/hu.po | 171 +++-- po/hu.po| 8 +- 3 files changed, 169 insertions(+), 223 deletions(-) diff --git a/WINGs/po/hu.po b/WINGs/po/hu.po index 8d875be..753edc4 100644 --- a/WINGs/po/hu.po +++ b/WINGs/po/hu.po @@ -7,8 +7,8 @@ msgid msgstr Project-Id-Version: Window Maker 0.95.5\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2014-02-16 18:47+0100\n -PO-Revision-Date: 2014-02-17 18:00+0100\n +POT-Creation-Date: 2014-02-18 00:14+0100\n +PO-Revision-Date: 2014-02-18 00:25+0100\n Last-Translator: BALATON Zoltán bala...@eik.bme.hu\n Language-Team: Hungarian\n Language: \n @@ -16,16 +16,16 @@ msgstr Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n -#: ../../../wmaker-crm/WINGs/error.c:68 -msgid fatal error: +#: ../../../wmaker-crm/WINGs/error.c:117 +msgid fatal: msgstr végzetes hiba: -#: ../../../wmaker-crm/WINGs/error.c:71 +#: ../../../wmaker-crm/WINGs/error.c:124 msgid error: msgstr hiba: -#: ../../../wmaker-crm/WINGs/error.c:74 -msgid warning: +#: ../../../wmaker-crm/WINGs/error.c:131 +msgid warn: msgstr figyelmeztetés: #: ../../../wmaker-crm/WINGs/findfile.c:58 @@ -133,9 +133,7 @@ msgid missing ; in PropList dictionary entry msgstr hiányzó ; a PropList szótár elemben #: ../../../wmaker-crm/WINGs/proplist.c:885 -msgid -was expecting a string, data, array or dictionary. If it's a string, try -enclosing it with \. +msgid was expecting a string, data, array or dictionary. If it's a string, try enclosing it with \. msgstr karakterlánc, adat, tömb vagy szótár tÃpusra számÃtottam. Ha karakterláncot adtál meg, próbáld idézÅjelbe tenni! #: ../../../wmaker-crm/WINGs/proplist.c:888 @@ -233,198 +231,197 @@ msgstr szürke msgid dark gray msgstr sötétszürke -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:384 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:383 msgid Colors msgstr SzÃnek -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:559 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2625 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:558 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2624 msgid Brightness msgstr Világosság -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:561 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:635 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:666 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:697 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:755 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:786 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:818 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:851 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:1989 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2627 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2661 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2695 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:560 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:634 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:665 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:696 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:754 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:785 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:817 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:850 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:1988 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2626 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2660 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2694 msgid Color Panel: Could not allocate memory msgstr SzÃn panel: nem sikerült a memória foglalás -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:633 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:632 msgid Red msgstr Piros -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:664 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:663 msgid Green msgstr Zöld -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:695 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:694 msgid Blue msgstr Kék -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:753 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:752 msgid Cyan msgstr Türkiz -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:784 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:783 msgid Magenta msgstr Lila -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:816 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:815 msgid Yellow msgstr Sárga -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:849 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:848 msgid Black msgstr Fekete -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:924 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:923 msgid Spectrum msgstr Spektrum -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:950 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:949 msgid Palette msgstr Paletta -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:955 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:954 msgid New from File... msgstr Ãj, fájlból... -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:956 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:1001 -#: ../../../wmaker-crm/WINGs
[PATCH] Updated Hungarian translation
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu --- WINGs/po/hu.po | 213 +--- WPrefs.app/po/hu.po | 171 +++-- po/hu.po| 8 +- 3 files changed, 169 insertions(+), 223 deletions(-) diff --git a/WINGs/po/hu.po b/WINGs/po/hu.po index 8d875be..753edc4 100644 --- a/WINGs/po/hu.po +++ b/WINGs/po/hu.po @@ -7,8 +7,8 @@ msgid msgstr Project-Id-Version: Window Maker 0.95.5\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2014-02-16 18:47+0100\n -PO-Revision-Date: 2014-02-17 18:00+0100\n +POT-Creation-Date: 2014-02-18 00:14+0100\n +PO-Revision-Date: 2014-02-18 00:25+0100\n Last-Translator: BALATON Zoltán bala...@eik.bme.hu\n Language-Team: Hungarian\n Language: \n @@ -16,16 +16,16 @@ msgstr Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n -#: ../../../wmaker-crm/WINGs/error.c:68 -msgid fatal error: +#: ../../../wmaker-crm/WINGs/error.c:117 +msgid fatal: msgstr végzetes hiba: -#: ../../../wmaker-crm/WINGs/error.c:71 +#: ../../../wmaker-crm/WINGs/error.c:124 msgid error: msgstr hiba: -#: ../../../wmaker-crm/WINGs/error.c:74 -msgid warning: +#: ../../../wmaker-crm/WINGs/error.c:131 +msgid warn: msgstr figyelmeztetés: #: ../../../wmaker-crm/WINGs/findfile.c:58 @@ -133,9 +133,7 @@ msgid missing ; in PropList dictionary entry msgstr hiányzó ; a PropList szótár elemben #: ../../../wmaker-crm/WINGs/proplist.c:885 -msgid -was expecting a string, data, array or dictionary. If it's a string, try -enclosing it with \. +msgid was expecting a string, data, array or dictionary. If it's a string, try enclosing it with \. msgstr karakterlánc, adat, tömb vagy szótár tÃpusra számÃtottam. Ha karakterláncot adtál meg, próbáld idézÅjelbe tenni! #: ../../../wmaker-crm/WINGs/proplist.c:888 @@ -233,198 +231,197 @@ msgstr szürke msgid dark gray msgstr sötétszürke -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:384 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:383 msgid Colors msgstr SzÃnek -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:559 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2625 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:558 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2624 msgid Brightness msgstr Világosság -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:561 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:635 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:666 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:697 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:755 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:786 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:818 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:851 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:1989 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2627 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2661 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2695 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:560 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:634 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:665 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:696 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:754 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:785 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:817 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:850 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:1988 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2626 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2660 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:2694 msgid Color Panel: Could not allocate memory msgstr SzÃn panel: nem sikerült a memória foglalás -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:633 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:632 msgid Red msgstr Piros -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:664 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:663 msgid Green msgstr Zöld -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:695 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:694 msgid Blue msgstr Kék -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:753 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:752 msgid Cyan msgstr Türkiz -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:784 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:783 msgid Magenta msgstr Lila -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:816 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:815 msgid Yellow msgstr Sárga -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:849 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:848 msgid Black msgstr Fekete -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:924 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:923 msgid Spectrum msgstr Spektrum -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:950 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:949 msgid Palette msgstr Paletta -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:955 +#: ../../../wmaker-crm/WINGs/wcolorpanel.c:954 msgid New from File... msgstr Ãj, fájlból... -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:956 -#: ../../../wmaker-crm/WINGs/wcolorpanel.c:1001 -#: ../../../wmaker-crm/WINGs
Re: [PATCH 2/3] WPrefs: Make Dock preferences pane less busy and fix up some strings
The patch doesn't apply since there was some activity in those files recently, making changes which apparently go in the opposite direction of your intentions with this patch (ie increase the space instead of decreasing). Can you take a look at the #next branch, especially commit 6a7fcb98ef and see if you still want to make changes? You could revert the above conflicting patch and apply mine instead, which may fix the truncation problem too as I've shortened the labels, thus making space for a less busy layout. I believe this is a better fix, although I haven't seen truncation in this pane before (with Luxi Sans size 12 font) so it may be dependent on the translation or font setting. If even more space is needed I suggest further reformulation by moving the word before from each line to the frame title such as: Clip autocollapsing delays before... autoexpand autocollapse Clip autoraising delays before... autoraise autolower instead of making the pane more crowded by decreasing space. There's a new place where I see truncation now on the next branch though: on the Mouse Preferences pane Acceler.: now became Accel. which is too short for any sensible Hungarian translation to fit here. Instead of making this space smaller again the Workspace Mouse Actions frame could be reformulated such as: Workspace Mouse Buttons X Disable mouse actions Left Middle Right Wheel (Maybe the Disable mouse actions toggle is redundant here as one could set all prefs to None for the same effect so it may be moved to the Expert pane too for an even cleaner layout.) I'm also sending an updated Hungarian translation patch for the strings changed between master and next (and some corrections I've found now). This can be folded into my previous patch. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 03/12] configure: Created new macro to append only once a flag to a variable
On Sun, 17 Nov 2013, Christophe wrote: From: Christophe CURIS christophe.cu...@free.fr Signed-off-by: Christophe CURIS christophe.cu...@free.fr --- m4/windowmaker.m4 | 19 +++ m4/wm_imgfmt_check.m4 | 12 ++-- 2 files changed, 25 insertions(+), 6 deletions(-) diff --git a/m4/windowmaker.m4 b/m4/windowmaker.m4 index 1eca694..08e74b5 100644 --- a/m4/windowmaker.m4 +++ b/m4/windowmaker.m4 @@ -102,3 +102,22 @@ $[]2], [ $[]3;])], AS_SET_STATUS([$wm_retval]) } ]) + + +# WM_APPEND_ONCE +# -- +# +# Append flags to a variable, but only if not already present +# +# Usage: MW_LIB_APPEND_ONCE([libflags], [variable]) There's a typo here: MW - WM Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
On Mon, 11 Nov 2013, Josip Deanovic wrote: I am using the newest version (#next branch) of Windowmaker and even when Seems to work for me with the latest release version on the master branch so it might be some of the recent patches. It should be possible to bisect this. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Shaded windows cannot get focus while cycling through the list of stacked windows
On Tue, 12 Nov 2013, Amadeusz Sławiński wrote:
I was able to reproduce it, it's broken with SwitchPanelImages = None
set. Can you check with this added to
${GNUSTEP_USER_ROOT}/Defaults/WindowMaker
(I have build from latest from next)
Indeed, it's reproducible on master too with this option in the config. So
it must be some earlier change then.
Regards,
BALATON Zoltan
Re: [PATCH v2] Updated default icons
On Sat, 19 Oct 2013, Doug Torrance wrote:
diff --git a/WindowMaker/Defaults/WMWindowAttributes.in
b/WindowMaker/Defaults/WMWindowAttributes.in
index 41dedf8..f182e51 100644
--- a/WindowMaker/Defaults/WMWindowAttributes.in
+++ b/WindowMaker/Defaults/WMWindowAttributes.in
@@ -2,82 +2,6 @@
Logo.WMDock = {Icon = GNUstepGlow.#extension#;};
Logo.WMPanel = {Icon = GNUstep.#extension#;};
Logo.WMClip = {Icon = clip.#extension#;};
- Dockit = {Icon = GNUstep.#extension#;};
- DockApp = {NoAppIcon = NO;};
- panel.Panel = {NoAppIcon = YES;};
[...]
- Kinput2 = {
- NoTitlebar = Yes;
- NoResizebar = Yes;
- NotClosable = Yes;
- NotMiniaturizable = Yes;
- KeepOnTop = Yes;
- Omnipresent = Yes;
- SkipWindowList = Yes;
- NoHideOthers = Yes;
- NoKeyBindings = Yes;
- NoMouseBindings = Yes;
- KeepInsideScreen = Yes;
- NoAppIcon = Yes;
- Unfocusable = Yes;
- DontSaveSession = Yes;
- };
[...]
- kjobviewer = {
-SkipWindowList = Yes;
-DontSaveSession = Yes;
-Unfocusable = Yes;
-NoAppIcon = Yes;
- };
- kio_uiserver = {NoAppIcon = Yes;};
- kcmshell = {NoAppIcon = Yes;};
- kded = {NoAppIcon = Yes;};
Although I don't use any of them, I don't know if it's a good idea to
remove sensible defaults for parts of common desktop environments like a
panel or an input manager. People using those environments could have a
bad initial experience like appicons overlapping or hiding behind a
panel, appicons for input windows or similar.
Regards,
BALATON Zoltan
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH 00/38] Help needed.
On Sun, 20 Oct 2013, Rodolfo García Peñas wrote: Ok, but then wmaker cannot be portable. I would like run wmaker on my Android. Create the things, and map in the X11, Android, Windows,... What do you want to use Window Maker for on Windows on Android? Its task is to manage windows and running applications on X. Where there's no X there's no need for an X Window Manager. Where an X window manager is useful it's no problem to depend on X Window System. Did I miss something? Regards, BALATON Zoltan
Re: wdm
On Sun, 22 Sep 2013, Rodolfo García Peñas wrote: I will adopt the wdm package for Debian. I saw that you have a fork in github and the upstream (email, homepage) doesn't exist anymore. Do you have more info? Do you remember this thread? http://thread.gmane.org/gmane.comp.window-managers.windowmaker.devel/4606 What kind of info do you need? Regards, BALATON Zoltan
Re: [PATCH 11/22] New struct wks_nfo
OK, it's getting clearer now. On Mon, 9 Sep 2013, Rodolfo García Peñas wrote: My aim is that the Clip, Drawer and the Dock will be the same internal object, but if it is the Clip, then it has some properties active and if it is the Dock, others. Same for the Drawers. Then the code is easier. So you want one single class that can be configured to behave like the Dock or the Clip or a Drawer? Wouldn't it be too complicated? Wouldn't it be a better object oriented design to have the common code in an abstract class and have the three specialised objects inherit from it and add/override what is needed? The last week I asked about why in the screen.c file, some code initilize more than one Dock. The reply was about the possibility of having multiple monitors, with different workspaces, and then different Docks. Maybe in a multiheaded X config with different screens. I never tried to run Window Maker on such a config so I don't know about that. Then, the code will be something like, if we have one or more workspaces, but all uses the same Dock, no problem, we have one Dock object in the Workspace[0] and the other workspaces has pointers to that Dock. If we have multiple workspaces, with different Docks, then, we have different objects. I think you mean instances of the above classes and want to share a single instance between multiple work spaces. Then I understand this. because currently the code in the wmaker start process binds the dock to the screen, not to the workspace, and I need rewrite some code to change the wmaker start process to create the screen, create the workspaces with the docks, and then bind them. I cannot do that yet, because I have problems with the dock menu (they need the WScreen struct, and I need indpendency with the screen to do it). Can't comment on this. But I just noticed that the Dock menu has an Add a drawer item but the Clip menu doesn't. Is there a way to add a drawer to the Clip? Regards, BALATON Zoltan
Re: Add dock icon to wmaker
On Sat, 11 May 2013, Rodolfo García Peñas (kix) wrote: is possible add that [1] icon to wmaker? I am thinking add the icon to the available icons in wmaker. Using it as default dock icon is other story. [1] http://lists.windowmaker.org/dev/msg04515.html I don't have that icon either that's why I was asking the same question but I never got an answer. Regards, BALATON Zoltan
Re: [PATCH 6/6] Docks menu bottom extra space
On Thu, 4 Apr 2013, Rodolfo García Peñas wrote: Remove the + 2 is ok, but I think we should thing in change the things to re-use the same functions. You can think of that but that's beyond fixing this bug. Anyway, if we remove the + 2 (line 3222), the problem with the Clip (probably Dock) is gone. But, the menu is hidden, you must move the mouse down to see it (you cannot see nothing). That's how it works if Scroll off screen menus option is turned on for app icons too and that's how it's supposed to work. In my patch, the menu is moved up 20 pixels, then, the first menú entry is painted in the screen and you know that the menu is there, partially hidden, but there. While this may seem like a good idea it isn't necessarily so because the rationale behind the scroll off screen menus feature is that menus should behave the same independent of screen position (to allow to build muscle memory and know that a certain down move will activate the same menu item everywhere instead of having to find it and aim at it constantly). Thus when using this option you're supposed to know the menu is there and don't need visual clues for that. (That said the current implementation is not perfect because the menu scrolls up too fast so it's still not the same amount of downward move to select menu entries as elswhere on the screen but that's probably another bug. Maybe the menu is now scrolled if the pointer is at the screen edge but should only be scrolled for downward move events instead. I didn't check if this theory is true though.) Regards, BALATON Zoltan
Re: [PATCH 6/6] Docks menu bottom extra space
On Thu, 4 Apr 2013, Daniel Déchelotte wrote: Before this patch, if the Dock/Clip is in the screen bottom, and clip to show the menu in the bottom area, the menu is hidden outside the screen. Sorry for chiming in without fully understanding the bug and the fix, but IIUC, wMenuMapAt() is given the preferred (x,y) coordinates where to display the menu. Then it is responsible for overriding them if the menu would appear off-screen and if asked by the user's preferences. IOW, the logic of we are too close to the border, let's move a bit should happen in wMenuMapAt, and only if the appropriate preference is set. No? As someone who uses the appropriate preference (Scroll off screen menus is on) tried it and seems that it works all right for app icons at the bottom of the screen but for docked app icons the menus are indeed inaccessible if the pointer is within two pixels of the bottom of the screen. These two pixels seem to also exist when menus are displayed elsewhere: App icon menus are open with the pointer touching their top (moving down one pixel selects the first menu item) while for docked/clipped appicons there's a two pixel gap between the pointer and the menu (only the third pixel down will select the menu). This might be something to do with this bug but I don't know where does it come from. Regards, BALATON Zoltan
Re: dockapps.git repo redesign question
On Thu, 4 Apr 2013, Carlos R. Mafra wrote: There _is_ a huge advantage in keeping things together and releasing them together. Depending on how you look at it. It may be less work for you but for users who only use one or two dockapps (which is typical) from the 40 you plan to release together means overhead and unecessary updates for unrelated changes in dockapps they don't even use. Same for packagers who might not even be the same person for all the included dockapps so distros should change their ways too. So it's not clear that this is an advantage for everyone. We should do the same here. These dockapps were mostly dead tarballs hidden somewhere, no maintainer no nothing. Why do we have to care about historic version numbers for them? It's time to move on and change. Let's refer to them as v3.0 collectively, it's much simpler. It's not about historic version numbers but trying to put unrelated things into one package which seems wrong. I tag the repo v3.0 and that's it. If wmbiff changes and no other dockapp changes, who cares if all of them become v3.1 one year later? It's the repo that's moving, not the individual dockapps. Yes but look at it from the users' point of view. Do they want to install all dockapps to only use wmnet? Do they care about changes in other dockapps and see updates for dockapps package while wmnet is still the same even if dockapps version has changed from 3.0 to 3.24? The problem happens when people consider the dockapps there individually and want to keep track of them individually. But this naturally happens. The dockapps are individual, they are developed individually (people only use a few and only care about those, submit patches for those). The only thing that holds them together is the common repo and nothing else. These are less related codes than drivers in your example because the drivers are all closely related to the kernel but dockapps are not related to each other nor really to Window Maker as other window managers support dockapps too. They're just put together in a repo trying to lower administrative overhead but this does not make them related. If you do that, it doesn't make sense to have them all in one repository in the first place and the difficulties pointed in this thread are related to trying to solve the wrong problem. And when you have the wrong problem to solve, no matter what you do it won't be the correct solution. Could there be a middle ground where we can have the advantages of both? Like keeping them in one repo but using separate version numbers and releasing them separately (either by tagging them separately or creating tarballs for release versions and putting them somewhere official)? I think this is what was proposed. What's your opinion on this? Yes, I agree with you. The solution is to treat them together or split them into 40 different repos. Or somewhere inbetween... I think the kernel viewpoint makes sense because it makes things simpler to manage. But it requires a small change in our mindset. IMO apart from the driver analogy does not really apply here it also may require a bit bigger change in distros' workflow so it does not make things easier for everyone. The other solution is to split the repo. But in this case I don't want to be the maintainer of 40 different repos, that's too much for me. How about keeping the common repo to make your job easier but keeping the tags and version numbers different for dockaps so unrelated changes don't cause updates for everyone. If git cannot tag individual directories we might adopt a convention like using tags like wmnet-1.1 wmbiff-2.0 etc. on the common repo so if someone wants to fetch a specific version of one dockapp would still be able to do that but tags are updated individually when the corresponding apps change. This way it would be a common repo and not 40 different ones but distros could choose to package dockapps separately. This seems to be the best for everyone and only a little more work because then you don't have to manage the release tarballs either. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 12/16] Add drawers to wmaker!
On Sat, 23 Mar 2013, Rodolfo García Peñas wrote: we want Drawers? Is only a question, I don't know if NeXT has Drawers. NeXT didn't have drawers AFAIK. It only had the dock which did what the dock is doing in Window Maker. Multiple desktops was added by a third party app called Fiend,app which also functions as an extended dock. There are some screenshots showing it here: http://www.shawcomputing.net/resources/next/software/openstep_screenshots/index.html (Fiend is the one with green \ buttons and Clip like workspace name and number in it's app icon) This is the history and the root of the difference between the Dock and Clip in Window Maker. Despite that drawers might be a good addition but as Carlos has pointed out there's already a dockapp which provides this functionality so it's questionable if it needs to be included in Window Maker. On Sat, 23 Mar 2013, Rodolfo García Peñas wrote: IMO, the Dock is a sub-type of Clip, and Drawers is a sub-type of Clip. This makes sense. If the code impelementing the Clip could be modified to support restrictions to behave like the Dock or Drawers it could be used in place of them. In that way we can think about remove Clip and Dock from wmaker, and add them as independent applications. Perhaps these applications could receive notifications about application/window actions (open, close, minimize,...). This might be a good idea but potentially difficult to implement. There might be issues with running multiple instances of this external Clip. Nevertheless it is an interesting idea. Regards, BALATON Zoltan
Re: Docks and AppIcons
but avoid mixing the two at least within one object class to make the code more readable. I hope these comments can be somewhat helpful even if not directly answering your questions. Regards, BALATON Zoltan
[PATCH] WPrefs: Fix single click activation button in Icon preferences
Patch attached. Regards, BALATON ZoltanFrom fa11ffa3c83f93353caf4af8689bbe28f3a9404b Mon Sep 17 00:00:00 2001 From: BALATON Zoltan bala...@eik.bme.hu Date: Fri, 8 Feb 2013 18:41:02 +0100 Subject: [PATCH] WPrefs: Fix single click activation button in Icon preferences Forgot to connect the button to the corresponding defaults key so it was not working properly. --- WPrefs.app/Icons.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/WPrefs.app/Icons.c b/WPrefs.app/Icons.c index 97b3c2f..98352a1 100644 --- a/WPrefs.app/Icons.c +++ b/WPrefs.app/Icons.c @@ -99,8 +99,8 @@ static void showData(_Panel * panel) char *def = blh; WMSetButtonSelected(panel-arrB, GetBoolForKey(AutoArrangeIcons)); - WMSetButtonSelected(panel-omnB, GetBoolForKey(StickyIcons)); + WMSetButtonSelected(panel-sclB, GetBoolForKey(SingleClickLaunch)); str = GetStringForKey(IconPosition); if (!str) @@ -287,6 +287,7 @@ static void storeData(_Panel * panel) SetBoolForKey(WMGetButtonSelected(panel-arrB), AutoArrangeIcons); SetBoolForKey(WMGetButtonSelected(panel-omnB), StickyIcons); + SetBoolForKey(WMGetButtonSelected(panel-sclB), SingleClickLaunch); SetIntegerForKey(WMGetPopUpButtonSelectedItem(panel-sizeP) * 8 + 24, IconSize); -- 1.7.10
Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.4-16-gfd7b117
On Wed, 30 Jan 2013, Carlos R. Mafra wrote: On Wed, 30 Jan 2013 at 7:50:02 +0100, Rodolfo García Peñas (kix) wrote: I don't know what to do. We can use the idea of set the textbox as non editable and use only the Browse... button to set it, but I am not sure about it. Apart from fixing real problems, I think you should do nothing about making it non editable or selecting things automatically and things like that. I agree that if you could make it work just like before the cleanup patches it would be enough. If you want to improve on that, checking if the text field has changed should also be possible by either observing appropriate notifications or registering your handler function as a delegate to the text field, but I don't know the details about this. Only looked at wtextfield.c briefly but it seems to contain the necessary mechanism to get notifications about changes. Regards, BALATON Zoltan
Re: [PATCH 3/4] 3 Save iconpath if icon will be used
Hello, On Sun, 27 Jan 2013, Rodolfo García Peñas wrote: better, but... I would like to know your oppinion before send the patches. My opinion is as before: code cleanup patches should not change behaviour so everything should work the same after your patches as they worked before them. (The last behaviour changing patch for icon.c selection seems to be ee1f13da45a8f3371a0dfe4a2a636c402ddf7b3d and the order is described in that commit message.) I can't offer help in checking code changes because I don't understand your code and don't have time to get knowledgeable about this part of Window Maker. So don't wait for comments about patches from me. The test case, test procedure and descriptions in my previous messages of how I think it should work were the best I could offer I'm afraid. Regards, BALATON Zoltan
Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.4-16-gfd7b117
On Sun, 27 Jan 2013, Rodolfo García Peñas wrote: Zoltan, test it!! :-) All should continue ok. Please, try it, you have a lot of knowledge about this. I don't have time for that but I gave you the procedure to test it yourself. If it passes that I'm fine with it too. I read the previous mail with Carlos, should I try to set the textbox to grey or something like to avoid that the user could edit it without set the checkbox? Don't touch the textbox. I said the switch should be grey when there's nothing in the textbox. Then the warning is not needed. Regards, BALATON Zoltan
Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.4-16-gfd7b117
On Sun, 27 Jan 2013, Carlos R. Mafra wrote: My understanding about the warning is that it tries to warn the user about a mistake he's doing. Yes but if you don't allow the user to make a mistake at the first place then there's no need for a warning. This is less confusing for the user than throwing a warning at him and letting him figure out what mistake he did. The user is saying I want wmaker to ignore the client icon and use the icon I set up for it. But at the same time he's not saying which icon wmaker is supposed to use instead (ie empty textbox). So the user should only be able to say this when it's meaningful to say so (i.e. there's an icon set and not otherwise). So I think the option should only be enabled when the file textbox is set and disabled if the user removes the file. No, the option should be enabled when the user ticks the option and disabled otherwise. It's supposed to be simple and have no correlation to the textbox. However, if the user ticks the 'ignore' option but does not define which icon to use, that's a mistake and it better be warned. No? I think there's a misunderstanding here. By disabled I mean greyed out, not selectable, inactive, etc. (cf. WMSetButtonEnabled and WMSetButtonSelected). The Ignore option and thus the switch button does have a correlation to the textbox as it's only meaningful to select it if there's an icon set. So it should not be active if it's invalid to select it. Does this make sense? Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/4] 3 Save iconpath if icon will be used
On Fri, 25 Jan 2013, Carlos R. Mafra wrote: On Fri, 25 Jan 2013 at 1:06:58 +0100, Rodolfo García Peñas wrote: I changed the behavior for the winspector. Can you test it now? More testers are welcome. If the patch is ok, I will write the commit info. I'm a bit lost about which behavior is being fixed. What is the test case to aim for? On the other hand, if Zoltan says it fixes his issues, I'll apply without testing it myself :-) I don't have time to test it now but I've described the problem, testing procedure and provided a test case in the thread starting at http://lists.windowmaker.org/dev/msg04395.html The test case is here: http://lists.windowmaker.org/dev/msg04396.html (Should show a white rectangle in the app icon which is the icon window.) The procedure to test Ignore app icon is here: http://lists.windowmaker.org/dev/msg04452.html Hope this helps. Regards, BALATON Zoltan
Re: Question about dock and clip (xrandr)
On Sun, 6 Jan 2013, Rodolfo García Peñas wrote: What do you think about the idea of the set clip in one of the four corners? Then, the clip will work with xrandr too. Do you mean that the clip could only be placed in one of the four corners and nowhere else? Then I don't think it's a good idea. Unless maybe if the clip could also be docked like any other appicon. To see why, here's a screenshot of my dock and clip: http://goliat.eik.bme.hu/~balaton/wmaker/OS42-WindowMaker_Screenshot.png (As a curiosity and for comparison I also included a window with OPENSTEP 4.2 running under QEMU.) I use the clip as a desktop specific dock extension so it's not tied to one of the corners. Maybe a solutions that could work is to store the clip position with relative coordinates, that is upper left: +0,+0 upper right: +0,-0 lower right: -0,-0 so always measure to the closest edge and store that instead of absolute position. IMO should be: ---8-- case ConfigureNotify: #ifdef HAVE_XRANDR if (event-xconfigure.window == DefaultRootWindow(dpy)) XRRUpdateConfiguration(event); #endif break; ---8-- Then why not even: #ifdef HAVE_XRANDR case ConfigureNotify: if (event-xconfigure.window == DefaultRootWindow(dpy)) XRRUpdateConfiguration(event); break; #endif And finally, someone knows whats happends when XRRUpdateConfiguration is called? What function/event is called in wmaker? Don't know anything about this but the man page says it is a callback to notify the xlib client side about changes in the screen configuration which is not done automatically to let clients decide when's the best time to call this. So no event is generated in wmaker but wmaker should call this if it gets an RRScreenChangeNotify, or ConfigureNotify (on the root window) according to the docs. Regards, BALATON Zoltan
Re: Reporting Bugs? (fwd)
Oops, wrong address... -- Forwarded message -- Date: Sun, 6 Jan 2013 16:46:15 +0100 (CET) From: BALATON Zoltan bala...@eik.bme.hu To: John Rash johnr...@gmail.com Cc: wmaker-de...@lists.windowmaker.org Subject: Re: Reporting Bugs? On 12/26/12, John Rashjohnr...@gmail.com wrote: and what really annoys me is how huge svg icons looks into docks (like from Nautilus/Caja (see that folder on the last icon), Chromium (that huge circle), etc.) - http://img803.imageshack.us/img803/4559/wmaker01.png - is there any I like the GNUstep cube logo on this screenshot. What do you think about making this the default dock icon instead of the current one which is now getting old and does not look good on new displays? Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about dock and clip (xrandr)
On Sun, 6 Jan 2013, Rodolfo García Peñas (kix) wrote: Yes, probably the option is check the screen size (p.e. 1024x768), then cut the screen in 4 areas: 1. (up-left)0x0 to (1024/2)x(768/2) 2. (up-right) (1024/2)x0 to 1024x(768/2) 3. (down-left) 0x(768/2) to (1024/2)x768 4. (down-right) (1024/2)x(768/2) to 1024x768 The idea is move the clip (and dock?) to the near edges, holding the distance to them. If the dock is in the up-left, we hold in that area, but if is near to the right down, then move to the new rigth down (holding the space to the finish. For example, if the old screen is 1024x768 and the new is 1920x1024 the final position to the initial position is: 1. Original 10x10, new 10x10 (no change) 2. Original 960x10, new 2048-(1024-960)x10 3. Original 10x700, new 10x(1024-(768-700) 4. Original 960x700, new 2048-(1024-960)x(1024-(768-700) Huh? It's a lot simpler than that (or I'm not really getting your calculations; where does 2048 come from in the 4th line?). I'd put it as the following: if your screen is 1024x768 and put the clip at 10,700 then in Position it is stored as +10-68 (by dividing the screen and checking for which quarter it's in as you described). Then when the resolution changes to 1920x1024 it is placed at 0+10,1024-68 which is at about the same relative position. This is also how the normal X geometry option works. Try these (although it also takes the window size in account to avoid putting the window off-screen): $ xclock -geometry +100+100 $ xclock -geometry +100-100 $ xclock -geometry -100-100 Then why not even: #ifdef HAVE_XRANDR case ConfigureNotify: if (event-xconfigure.window == DefaultRootWindow(dpy)) XRRUpdateConfiguration(event); break; #endif I don't like it, because in my code the case option is used (if no xrand, nothing happends), but in your code the option is not selected, then the switch will check the next options. And, if this switch-case has default option, in my code is not selected, but in your code the default option is selected. OTOH, this case could be used in the future to other things, not only for xrandr. You're right. But the next case is the default: case which calls handleExtensions() that is a function well equipped with #ifdefs and already has a case for XRANDR too so probably the above should be moved there and then the whole ConfigureNotify case could be removed. (There's not much point in keeping empty cases as you can always add them when you actually need them.) I'm also not sure if we need both the ConfigureNotify on the root window and the RRScreenChangeNotify considering the wording with or in the man page. Ok, I am busy now, but I will check it in the future (after finish with your comments about appicon). OK, thanks. :-) Regards, BALATON Zoltan
Re: Problem with xfig
On Tue, 27 Nov 2012, Rodolfo García Peñas (kix) wrote: did you try the current next branch? This problem is not fully solved, but I think the button does things. I'm running the next branch and it's not working correctly. Here's what I see: 1. Start xcalc and open Icon and Initial Workspace inspector you probably will see the icon pointing to a file in the cache and the Ignore client supplied icon option ticked 2. Delete the file name from the text field and untick the Ignore option then click save and check that there is no section now for XCalc in WMWindowAttributes. This should be the initial state when an application is first run. Now you can continue testing. 3. Close xcalc then start it again and see what happened in the inspector. Also check what's in WMWindowAttributes and note that the Ignore attribute is not consistent. (It is checked in the GUI but not set in the config.) All this should not happen as the cached image should not be added to the config file at the first place but let's continue testing. 4. Uncheck the Ignore option in the inspector and try to select an icon then click apply. See that nothing happens. 5. Click save, the icon has changed now in the appicon and also set in the config file but try to minimise the window and see that the miniwindow does not have the correct icon. 6. Now just close the app and restart it. Try minimising the window and the icon is now also set in the miniwindow. Check the inspector and see that the Ignore option is magically ticked now while it's still not set in WMWindowAttributes. I think there are still some things left to fix to untangle this mess as this cannot be the correct behaviour. Most of this seems to be some breakage of the Ignore client supplied icon option. Regards, BALATON Zoltan
Re: Problem with xfig
On Sun, 25 Nov 2012, Rodolfo García Peñas wrote: I am not sure if the testing application is working. The application only show a dock (miniwindow) with a white square inside. kix@osaka:~/src/wmaker/wmaker-crm/src$ /home/kix/wmicontest Opened display :1 XCreateSimpleWindow returned: 341 XCreateSimpleWindow returned: 342 XMapWindow returned: 1 Read it before you run it! Press enter to move on to the next step when it opens a window. You can try to minimise it. Then press enter again (in the terminal you've started it from) to finish. If I run it with the lines commented, then the application doesn't have the white square. That means it would break apps which display something in their appicon. Did you try dockapps? (The white square is the icon window.) Regards, BALATON Zoltan
Re: Problem with xfig
On Sun, 25 Nov 2012, Rodolfo García Peñas wrote: The problem is because the icon-icon_win == None. See the wIconUpdate function at [1]. This function is different than the next branch, I did a lot of changes, but the idea is the same. See the flow with the removed lines: icon_create_for_wwindow set_icon_for_window: wIconUpdate wIconUpdate icon 0x936cd0 wwin 0x93f000 flag 0 wIconUpdate:get_rimage_icon_from_user_icon 4 icon 0x936cd0 wIconUpdate icon 0x936cd0 wwin 0x93f000 flag 0 wIconUpdate:get_rimage_icon_from_user_icon 4 icon 0x936cd0 Or with the lines (original code/next code): icon_create_for_wwindow set_icon_for_window: wIconUpdate wIconUpdate icon 0x19bfd30 wwin 0x19c1a90 flag 0 wIconUpdate:get_rimage_icon_from_icon_win 2 icon 0x19bfd30 wIconUpdate icon 0x19bfd30 wwin 0x19c1a90 flag 0 wIconUpdate:get_rimage_icon_from_icon_win 2 icon 0x19bfd30 If I remove the lines, then icon-icon_win == None, and then jump to the default icon. Else, get the icon from the wm_hints/net_icon_image. I didn't understand a word from this but I hope you understand and know what you are doing. Just make sure that the test application still works the same after your changes please. About your question about dockapps, they are fine here. Why? I was asking because they work the same as the test case I've sent (start in withdrawn state and use their window as an icon window). Dockapps works in a extrange way. The try to get the image for their dock. If the image is found, then, they set the image, else, set the wmaker default image. Whats happend if the application is running, then, the application background is set to the tile background (grey/blue/...), and the put the application inside the icon. But it the application is not running, the icon for the application is painted. If you click on the dockapp, the icon image is removed, the background is set and the application is put inside the icon. What if the dockapp is not yet docked but started from the command line? Regards, BALATON Zoltan
Re: Problem with xfig
On Mon, 26 Nov 2012, Rodolfo García Peñas wrote: Thanks for your reply. But I don't know what to do now. I don't know either. Are there any problems you know about that should be fixed or everything is fixed now? I've lost track. Regards, BALATON Zoltan
Re: Problem with xfig
On Sat, 24 Nov 2012, Rodolfo García Peñas wrote:
The problem seems to be that icon-icon_win is not NULL :-)
That's not a problem. Some apps may have an icon window instead of a
static icon (maybe they want to display something in the icon). Rather the
problem might be that it is not ignored when the ignore client supplied
icon option is set.
These code was there, but I am not sure if we can drop it?
I tried other apps, and all was fine.
Not sure either but you could try the attached test case (and check that
minimising the window is OK too as the comment suggests that it may have
something to do with that).
Regards,
BALATON Zoltan#include stdlib.h
#include stdio.h
#include X11/Xlib.h
#include X11/Xutil.h
Display *d;
Window leader, mainwin, win;
XClassHint class_hint = { wmicontest, WMIconTest };
int main(int argc, char **argv)
{
int ret;
XWMHints hints;
d = XOpenDisplay(NULL);
if ( !d )
{
fprintf(stderr,Cannot open display: %s\n, XDisplayName(NULL));
exit(EXIT_FAILURE);
}
printf(Opened display %s\n, DisplayString(d));
/* Create the leader window */
leader = XCreateSimpleWindow(d, /* Display */
DefaultRootWindow(d), /* Parent */
10, 10, /* x, y */
10, 10, /* width, height */
0, /* border_width */
BlackPixel(d, DefaultScreen(d)), /* border */
WhitePixel(d, DefaultScreen(d))); /* background */
printf(XCreateSimpleWindow returned: %lx\n, leader);
/* Create the main window */
mainwin = XCreateSimpleWindow(d, /* Display */
DefaultRootWindow(d), /* Parent */
0, 0, /* x, y */
56, 56, /* width, height */
0, /* border_width */
BlackPixel(d, DefaultScreen(d)), /* border */
WhitePixel(d, DefaultScreen(d))); /* background */
printf(XCreateSimpleWindow returned: %lx\n, mainwin);
/* Set hints */
XSetClassHint(d, leader, class_hint);
hints.flags = StateHint|WindowGroupHint|IconWindowHint;
hints.initial_state = WithdrawnState;
hints.window_group = leader;
hints.icon_window = mainwin; /* Use the main window as the icon window */
XSetWMHints(d, leader, hints);
XSetClassHint(d, mainwin, class_hint);
hints.flags = StateHint|WindowGroupHint;
hints.initial_state = NormalState;
XSetWMHints(d, mainwin, hints);
ret = XMapWindow(d, leader);
printf(XMapWindow returned: %x\n, ret);
XSync(d, False);
getchar();
/* Create a window */
win = XCreateSimpleWindow(d, /* Display */
DefaultRootWindow(d), /* Parent */
100, 100, /* x, y */
100, 100, /* width, height */
0, /* border_width */
BlackPixel(d, DefaultScreen(d)), /* border */
WhitePixel(d, DefaultScreen(d))); /* background */
printf(XCreateSimpleWindow returned: %lx\n, win);
/* Set hints */
XSetClassHint(d, win, class_hint);
XSetWMHints(d, win, hints);
ret = XMapRaised(d, win);
printf(XMapRaised returned: %x\n, ret);
XSync(d, False);
getchar();
XCloseDisplay(d);
return(EXIT_SUCCESS);
}
Re: Patch: Prevent windows from drifting on restart
On Fri, 16 Nov 2012, Iain Patterson wrote: With these two extra patches there should be no more drifting. Unfortunately I've found an app which now exhibits drifting with current #next while it had no problem before. The window of Deadbeef (with the gtk3 UI plugin in case it matters) is now drifting upwards by about the size of its window decoration whenever it's mapped (when it is first opened or after being closed and reopened by clicking on the tray icon). Any ideas? The app is available at deadbeef.sf.net some of its window properties are: _NET_WM_STATE(ATOM) = _NET_WM_DESKTOP(CARDINAL) = 0 _NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 25, 9 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 288 by 138 program specified base size: 0 by 0 window gravity: NorthWest xwininfo: Window id: 0x186 DeaDBeeF-0.5.6 Absolute upper-left X: 302 Absolute upper-left Y: 456 Relative upper-left X: 0 Relative upper-left Y: 24 Width: 907 Height: 555 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +302+456 -71+456 -71-13 +302-13 -geometry 907x555-70-4 after closing the window and reopening via the tray icon: xwininfo: Window id: 0x186 DeaDBeeF-0.5.6 Absolute upper-left X: 301 Absolute upper-left Y: 431 Relative upper-left X: 0 Relative upper-left Y: 24 Width: 907 Height: 555 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +301+431 -72+431 -72-38 +301-38 -geometry 907x555-71-29 Let me know if you need more info or help in debugging. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
On Sun, 18 Nov 2012, BALATON Zoltan wrote: The app is available at deadbeef.sf.net some of its window properties are: Some more info which may be helpful. The app seems to save its window positions (gtk_window_get_position, gtk_window_get_size) and tries to restore them before showing the window via gtk_window_move and gtk_window_resize (or gtk_window_maximize if it was maximised). This seems to make it drift. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/6] wIconUpdate wwin checks
On Sat, 17 Nov 2012, Rodolfo García Peñas wrote:
The variable wwin is only used in one block of the if, so should be moved
inside this block. OTOH, is better check if the variabl exists before
assign it. The code now is more stable and avoid crashes.
You are right but...
diff --git a/src/icon.c b/src/icon.c
index ddcf167..de766ad 100644
--- a/src/icon.c
+++ b/src/icon.c
@@ -601,11 +601,14 @@ static void unset_icon_image(WIcon *icon)
void wIconUpdate(WIcon *icon, RImage *image)
{
- WWindow *wwin = icon-owner;
+ WWindow *wwin = NULL;
if (image) {
icon-file_image = image;
^^
..if icon is NULL it may crash here. Apparently it is invalid to call
this function without icon being non-NULL so maybe instead of checking for
it at every place you could just put an assert(icon != NULL) at the
beginning (or if (!icon) return; if that's what should happen instead).
} else {
+ if (icon icon-owner)
+ wwin = icon-owner;
+
if (wwin WFLAGP(wwin, always_user_icon)) {
/* Forced use user_icon */
get_rimage_icon_from_user_icon(icon);
Re: [PATCH 6/6] applySettings icon set updated
On Sat, 17 Nov 2012, Rodolfo García Peñas wrote: I found other problem :-( If we set icon and save, in the dockapp or winspector, the minimized applications lost the icon. Restore and minimize again recovers the icon, but is not correct. This behavior is worst than without the patches. I will continue with this problem, but feel free to remove the patches (rollback), help with them, etc. Sorry, I can't help with fixing icon stuff, I can only tell what I saw in the hope that these may be useful finding some bugs. Everything seems to work but whenever I minimize and then restore a window I see an error like this: wmaker(catchXError(../../wmaker-crm/src/startup.c:177)): warning: internal X error: RenderBadPicture (invalid Picture parameter) Request code: 153 Request minor code: 7 Resource ID: 0x8000fe Error serial: 33925 Another strange thing I've found is that xpdf does not have an appicon even though I have nothing in the config or options which would prevent this. The only thing in WMWindowAttributes is an Icon line pointing to the CachedPixmaps/win.Xpdf.xpm. (It also has the Application specific page in the inspector grayed out.) Other apps have the appicon so it may be something with xpdf. Another strange app is xpdf which seems to use its own icon in the miniwindow instead of the icon set for it despite the Ignore client supplied icon option being set. It shows the icon I set in the appicon but not in the miniwindow. This works for other apps though so again it may be something with xfig and not Window Maker. Other than the invalid picture error everything seems to progress nicely. Thanks for your work on Window Maker. Regards, BALATON Zoltan
Re: [PATCH 6/6] applySettings icon set updated
On Sun, 18 Nov 2012, BALATON Zoltan wrote: Another strange app is xpdf which seems to use its own icon in the miniwindow Sorry, I meant xfig. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] get_wwindow_image_from_wmhints scale image
On Fri, 16 Nov 2012, Rodolfo García Peñas (kix) wrote: I am busy these days :-( a lot of work. I will try to release the patch about winspector these weekend. Sorry for the delay. No problem, do it when you have free time, it can wait until you can work on it. Therefore, the image is resized (if needed) only one time when the application is running. This sounds good. Thanks for the explanation. - Images are also enlarged when they are too small? This may look bad so probably there could be a limit (say no more than 2x) or only scale down images if they are too big but never enlarge them. No. But could be easy to implement. Now, all image resize is done at wIconValidateIconSize(). This function is quick, because see the image width and height and resize it only if the image is bigger than the icon size. If you want it, I can do it. I am not sure about the quality of the resize image, but I think wrlib includes some functions to do it fine. I don't know how much of a problem can this be practically so I let you decide about it. Just brought up this for consideration as I was thinking about it. If it can be done easily anytime we see a practical example it may be good enough as it is and could be fixed when we have a bug report in the future. Yes. I am working in the patch. I will try to release the patches this weekend. Thanks again. Regards, BALATON Zoltan
[PATCH 1/2] Made highlighting the AppIcon of the active app configurable at run time
---
WPrefs.app/Expert.c | 14 +-
src/WindowMaker.h |6 +++---
src/actions.c |8 +---
src/appicon.c |2 ++
src/application.c |5 -
src/defaults.c |2 ++
src/icon.c |2 --
src/icon.h |3 +--
src/wconfig.h.in|3 ---
src/window.c|3 ++-
10 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/WPrefs.app/Expert.c b/WPrefs.app/Expert.c
index f897384..177bbd8 100644
--- a/WPrefs.app/Expert.c
+++ b/WPrefs.app/Expert.c
@@ -22,9 +22,9 @@
#include WPrefs.h
#ifdef XKB_MODELOCK
-#define NUMITEMS 10
+#define NUMITEMS 11
#else
-#define NUMITEMS 9
+#define NUMITEMS 10
#endif
typedef struct _Panel {
@@ -56,8 +56,9 @@ static void showData(_Panel * panel)
WMSetButtonSelected(panel-swi[6], GetBoolForKey(AntialiasedText));
WMSetButtonSelected(panel-swi[7],
GetBoolForKey(CycleActiveHeadOnly));
WMSetButtonSelected(panel-swi[8], GetBoolForKey(ShowClipTitle));
+ WMSetButtonSelected(panel-swi[9], GetBoolForKey(HighlightActiveApp));
#ifdef XKB_MODELOCK
- WMSetButtonSelected(panel-swi[9], GetBoolForKey(KbdModeLock));
+ WMSetButtonSelected(panel-swi[10], GetBoolForKey(KbdModeLock));
#endif /* XKB_MODELOCK */
}
@@ -98,13 +99,15 @@ static void createPanel(Panel * p)
WMSetButtonText(panel-swi[6], _(Smooth font edges (needs restart).));
WMSetButtonText(panel-swi[7], _(Cycle windows only on the active
head.));
WMSetButtonText(panel-swi[8], _(Show workspace title on Clip.));
+ WMSetButtonText(panel-swi[9], _(Highlight the icon of the application
when it has the focus.));
#ifdef XKB_MODELOCK
- WMSetButtonText(panel-swi[9], _(Enable keyboard language switch
button in window titlebars.));
+ WMSetButtonText(panel-swi[10], _(Enable keyboard language switch
button in window titlebars.));
#endif /* XKB_MODELOCK */
/* If the item is default true, enable the button here */
WMSetButtonEnabled(panel-swi[6], True);
WMSetButtonEnabled(panel-swi[8], True);
+ WMSetButtonEnabled(panel-swi[9], True);
WMMapSubwidgets(panel-box);
WMSetScrollViewContentView(sv, WMWidgetView(f));
@@ -128,8 +131,9 @@ static void storeDefaults(_Panel * panel)
SetBoolForKey(WMGetButtonSelected(panel-swi[6]), AntialiasedText);
SetBoolForKey(WMGetButtonSelected(panel-swi[7]),
CycleActiveHeadOnly);
SetBoolForKey(WMGetButtonSelected(panel-swi[8]), ShowClipTitle);
+ SetBoolForKey(WMGetButtonSelected(panel-swi[9]), HighlightActiveApp);
#ifdef XKB_MODELOCK
- SetBoolForKey(WMGetButtonSelected(panel-swi[9]), KbdModeLock);
+ SetBoolForKey(WMGetButtonSelected(panel-swi[10]), KbdModeLock);
#endif /* XKB_MODELOCK */
}
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 804695b..ca89299 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -351,12 +351,12 @@ typedef struct WPreferences {
#endif
char no_dithering;/* use dithering or not */
char no_animations; /* enable/disable animations */
-char no_autowrap; /* wrap workspace when window is moved
-* to the edge */
+char no_autowrap; /* wrap workspace when window is moved
to the edge */
+char highlight_active_app; /* show the focused app by highlighting
its icon */
char auto_arrange_icons; /* automagically arrange icons */
char icon_box_position; /* position to place icons */
-signed char iconification_style; /* position to place icons */
+signed char iconification_style; /* position to place icons */
char disable_root_mouse; /* disable button events in root window
*/
char auto_focus; /* focus window when it's mapped */
char *icon_back_file; /* background image for icons */
diff --git a/src/actions.c b/src/actions.c
index 7dceaff..a79de8a 100644
--- a/src/actions.c
+++ b/src/actions.c
@@ -136,7 +136,8 @@ void wSetFocusTo(WScreen *scr, WWindow *wwin)
if (oapp) {
wAppMenuUnmap(oapp-menu);
- wApplicationDeactivate(oapp);
+ if (wPreferences.highlight_active_app)
+ wApplicationDeactivate(oapp);
}
WMPostNotificationName(WMNChangedFocus, NULL, (void *)True);
@@ -199,7 +200,8 @@ void wSetFocusTo(WScreen *scr, WWindow *wwin)
if (oapp oapp != napp) {
wAppMenuUnmap(oapp-menu);
- wApplicationDeactivate(oapp);
+ if (wPreferences.highlight_active_app)
+ wApplicationDeactivate(oapp);
}
}
@@ -213,7 +215,7 @@ void wSetFocusTo(WScreen *scr, WWindow *wwin)
if (wwin-flags.mapped)
wAppMenuMap(napp-menu,
Re: [PATCH 1/2] Made highlighting the AppIcon of the active app configurable at run time
On Sat, 17 Nov 2012, Carlos R. Mafra wrote: I don't like having a configurable switch for trivial things like this. I guess that most users simply don't care about one way or another. High-level switches like having icons or not is what should be aimed for. Once you make a high-level choice, you basically get what you get. What basically means is not well-defined of course, but I think that this patch goes a bit beyond. There has to be some limit for pickiness. I don't understand what you don't like about this patch since this is not even adding a new option. This option has always been there in wconfig.h (as NEWAPPICON) but there was no way to change it at runtime. My patch simply makes it runtime configurable and adds an option to the expert panel which already has switches for things like using save under or not or having selection animation of icons. This option is not more picky than those. Moreover I took care not to change the default behaviour either so most users don't have to care about it at all and this also removes a #define and corresponding #ifdefs so it can count as a cleanup. Having this option configurable only at compile time has been a reason for me to always have to compile my own version of Window Maker instead of being able to use the package that comes with the distribution. I can continue compiling my own version of course (looking at flashing and washed out icons is not an option for me) but merging this patch would make at least one of your user's life easier without doing anyone else any harm so I don't see why you would not take it. Of course it's your decision as a maintainer but you could reconsider it. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] get_wwindow_image_from_wmhints scale image
On Wed, 14 Nov 2012, Rodolfo García Peñas wrote: Then, the image can be resized using wIconValidateIconSize(). The resize should be done in get_rimage_icon_from_wm_hints(), not in the function get_wwindow_image_from_wmhints(). This is because the function get_wwindow_image_from_wmhints() is used in wIconStore() too. If we resize the image before save it to disk, then if we change the icon/dock size, then the image saved will have a different size than the curren icon size. Is better resize the image when is painted in the screen, not the image saved. Thanks a lot for fixing all this. I couldn't really follow all your changes so I'm not sure how it all works now so here are some questions/thoughts. I think you've thought about these already but asking it just in case: - This does not mean that the image is resized every time it is painted, does it? If yes then it may be faster to check the size of the cached image before using it and remove it when the icon size has been changed. - Images are also enlarged when they are too small? This may look bad so probably there could be a limit (say no more than 2x) or only scale down images if they are too big but never enlarge them. - Is it possible to change icons of applications without restarting them (the Apply button in the inspector is working) and does the ignore client supplied icon option work? Regards, BALATON Zoltan
[PATCH] WPrefs: Move around some options between pages
Move bounce options from expert prefs to its own box on ergonomic
prefs to have them at one place which makes them somewhat more clear.
The options previously occupying this place have been moved to other
pages where they better belong.
---
WPrefs.app/Expert.c | 39
WPrefs.app/Focus.c | 12 ++--
WPrefs.app/Preferences.c | 49 +++---
3 files changed, 57 insertions(+), 43 deletions(-)
diff --git a/WPrefs.app/Expert.c b/WPrefs.app/Expert.c
index b14f549..5d539fc 100644
--- a/WPrefs.app/Expert.c
+++ b/WPrefs.app/Expert.c
@@ -21,6 +21,12 @@
#include WPrefs.h
+#ifdef XKB_MODELOCK
+#define NUMITEMS 12
+#else
+#define NUMITEMS 11
+#endif
+
typedef struct _Panel {
WMBox *box;
char *sectionName;
@@ -31,7 +37,7 @@ typedef struct _Panel {
WMWidget *parent;
- WMButton *swi[14];
+ WMButton *swi[NUMITEMS];
} _Panel;
@@ -51,10 +57,10 @@ static void showData(_Panel * panel)
WMSetButtonSelected(panel-swi[7], GetBoolForKey(SingleClickLaunch));
WMSetButtonSelected(panel-swi[8],
GetBoolForKey(CycleActiveHeadOnly));
WMSetButtonSelected(panel-swi[9], GetBoolForKey(ShowClipTitle));
- WMSetButtonSelected(panel-swi[10],
GetBoolForKey(BounceAppIconsWhenUrgent));
- WMSetButtonSelected(panel-swi[11],
GetBoolForKey(RaiseAppIconsWhenBouncing));
- WMSetButtonSelected(panel-swi[12],
GetBoolForKey(OpaqueMoveResizeKeyboard));
- WMSetButtonSelected(panel-swi[13],
GetBoolForKey(DoNotMakeAppIconsBounce));
+ WMSetButtonSelected(panel-swi[10],
GetBoolForKey(OpaqueMoveResizeKeyboard));
+#ifdef XKB_MODELOCK
+ WMSetButtonSelected(panel-swi[11], GetBoolForKey(KbdModeLock));
+#endif /* XKB_MODELOCK */
}
static void createPanel(Panel * p)
@@ -75,10 +81,10 @@ static void createPanel(Panel * p)
WMSetScrollViewHasHorizontalScroller(sv, False);
f = WMCreateFrame(panel-box);
- WMResizeWidget(f, 495, sizeof(panel-swi) / sizeof(char *) * 25 + 8);
+ WMResizeWidget(f, 495, NUMITEMS * 25 + 8);
WMSetFrameRelief(f, WRFlat);
- for (i = 0; i sizeof(panel-swi) / sizeof(char *); i++) {
+ for (i = 0; i NUMITEMS; i++) {
panel-swi[i] = WMCreateSwitchButton(f);
WMResizeWidget(panel-swi[i], FRAME_WIDTH - 40, 25);
WMMoveWidget(panel-swi[i], 5, 5 + i * 25);
@@ -95,15 +101,14 @@ static void createPanel(Panel * p)
WMSetButtonText(panel-swi[7], _(Launch applications and restore
windows with a single click.));
WMSetButtonText(panel-swi[8], _(Cycle windows only on the active
head.));
WMSetButtonText(panel-swi[9], _(Show workspace title on Clip.));
- WMSetButtonText(panel-swi[10], _(Bounce AppIcons when the application
wants attention.));
- WMSetButtonText(panel-swi[11], _(Raise AppIcons when bouncing.));
- WMSetButtonText(panel-swi[12], _(Opaque Move,Resize with keyboard.));
- WMSetButtonText(panel-swi[13], _(Do not make AppIcons bounce.));
+ WMSetButtonText(panel-swi[10], _(Opaque Move,Resize with keyboard.));
+#ifdef XKB_MODELOCK
+ WMSetButtonText(panel-swi[11], _(Enable keyboard language switch
button in window titlebars.));
+#endif /* XKB_MODELOCK */
/* If the item is default true, enable the button here */
WMSetButtonEnabled(panel-swi[6], True);
WMSetButtonEnabled(panel-swi[9], True);
- WMSetButtonEnabled(panel-swi[10], True);
WMMapSubwidgets(panel-box);
WMSetScrollViewContentView(sv, WMWidgetView(f));
@@ -128,10 +133,10 @@ static void storeDefaults(_Panel * panel)
SetBoolForKey(WMGetButtonSelected(panel-swi[7]), SingleClickLaunch);
SetBoolForKey(WMGetButtonSelected(panel-swi[8]),
CycleActiveHeadOnly);
SetBoolForKey(WMGetButtonSelected(panel-swi[9]), ShowClipTitle);
- SetBoolForKey(WMGetButtonSelected(panel-swi[10]),
BounceAppIconsWhenUrgent);
- SetBoolForKey(WMGetButtonSelected(panel-swi[11]),
RaiseAppIconsWhenBouncing);
- SetBoolForKey(WMGetButtonSelected(panel-swi[12]),
OpaqueMoveResizeKeyboard);
- SetBoolForKey(WMGetButtonSelected(panel-swi[13]),
DoNotMakeAppIconsBounce);
+ SetBoolForKey(WMGetButtonSelected(panel-swi[10]),
OpaqueMoveResizeKeyboard);
+#ifdef XKB_MODELOCK
+ SetBoolForKey(WMGetButtonSelected(panel-swi[11]), KbdModeLock);
+#endif /* XKB_MODELOCK */
}
Panel *InitExpert(WMScreen * scr, WMWidget * parent)
@@ -143,7 +148,7 @@ Panel *InitExpert(WMScreen * scr, WMWidget * parent)
panel-sectionName = _(Expert User Preferences);
panel-description = _(Options for people who know what they're
doing...\n
- Also have some other misc. options.);
+ Also has some other misc. options.);
panel-parent = parent;
diff --git a/WPrefs.app/Focus.c b/WPrefs.app/Focus.c
index
Re: Call for testing before 0.95.4
On Wed, 14 Nov 2012, Rodolfo García Peñas wrote: Anyway, I am so happy with the new code, because as you can see, is more easy, but yes, some things could be better. Alt+tab show a correct icon too. Thanks A LOT for your report. I'm happy with the improvements too and the problems I've sent are not that serious indeed but fixing them could make it even better. PS2. I will reply your other questions tomorrow. Don't rush it. I think we don't have a hard deadline and we can make the release a few days or weeks later if that allows us to fix more bugs and make a better release. So take your time to think about it and sleep when you need. :-) Regards, BALATON Zoltan
Re: Problems with focus
On Sun, 4 Nov 2012, Rodolfo García Peñas wrote: If you run these applications, and hit Alt+Tab you cannot select them. Opening the inspection window, the flag in Do not let it take focus is set. If you deselect it and click in apply, then you can select it in Alt+Tab. But if you click on Save, the next time you lauch the application, the flag is set again. Could it be this property? (xprop is your friend.) WM_HINTS(WM_HINTS): Client accepts input or input focus: False Regards, BALATON Zoltan
Re: Help with Atom (window/icon titles)
On Fri, 2 Nov 2012, Rodolfo García Peñas wrote: Same problem with xfig :-) Not really the same... Xfig does set WM_ICON_NAME property, but sets it to the name of the file it's editing. So when just started and the fig is not saved it sets an empty icon title but try saving it or opening a fig file and see that then it displays the file name in the icon title. :-) Regards, BALATON Zoltan
Re: Help with Atom (window/icon titles)
On Thu, 1 Nov 2012, Carlos R. Mafra wrote: On Thu, 1 Nov 2012 at 1:09:52 +0100, Rodolfo García Peñas wrote: The icons are now better, all with titles :-) The question is: Should we use the window name in icons? Perhaps, do something like use the icon name, but if it is NULL, use the window name? According to the relevant standard this is what's intended: http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html Regards, BALATON Zoltan
Re: Help with Atom (window/icon titles)
On Fri, 2 Nov 2012, Rodolfo García Peñas wrote: may be incorrect. What application does have this problem. Could this be a bug on that application's side instead? gitk, but the application has title. Looks like gitk only sets the WM_NAME (and _NET_WM_NAME) properties and does not set an icon name. Here's a patch (to gitk) to fix it: --- gitk.orig 2012-04-08 18:23:57.0 +0200 +++ gitk2012-11-02 02:06:35.129295195 +0100 @@ -11830,6 +11830,7 @@ # wait for the window to become visible tkwait visibility . wm title . $appname: [reponame] +wm iconname . $appname: [reponame] update readrefs With this it has a name also when iconified so I think it's really a bug in gitk. If you insist to have a fallback for a missing icon name in Window Maker then WM_CLASS looks like what is used elsewhere as far as I could find because that's usually short while WM_NAME is meant to be the title of the window and can be longer than what would fit an icon. Regards, BALATON Zoltan
Re: Patch: Partial support for partial struts
On Wed, 31 Oct 2012, Carlos R. Mafra wrote: My first impression is that wArrangeIcons() should be called when appicons are removed (because they can leave a hole). But when they are created, why do we care? Aren't they simply supposed to be appended (eg to the right) of the existing appicons? I'm not completely sure about that but I think Auto-arrange icons also makes sure that app icons and miniwindows are not mixed together but appicons precede miniwindows. This means that miniwindows may need to be shifted if a new appicon is created and also when removed. Does that make sense? Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Bill Paul... (was: Re: Grab problem)
On Thu, 9 Aug 2012, Alexey I. Froloff wrote: On Thu, Aug 09, 2012 at 01:04:24PM +0200, Rodolfo kix Garcia wrote: On 09/08/12 11:44, BALATON Zoltan wrote: Thanks BALATON for your reply. Zoltan is from Hungary, they use LAST First instead of First Last ;-) That's right, thank you. This is why it's capitalised that way but not everyone knows this convention. This reminds me epic thread - http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/014882.html :-) Fortunately I'm not that upset if someone gets it wrong. (By the way watching the broadcast from the Olympics I noticed that they got it right for Chinese names and maybe Korean but still not for Japanese and Hungarian.) As for Kix' question, I think that a perfectly working feature should not be removed just because someone is annoyed by it (there was only one bug report so it seems most people were OK with it except the one who sent the bug report). For the same reason there's no need to change the default and the few people who don't like it can change their Prefs easily. The same grab also happens when resizing windows. What would you do about that? If you want to avoid the freeze in display when just pressing the mouse button without moving it then you might try to move the start of the grab to the first Motion event like it's done when resizing a window. But now that we know it it might be useful sometimes if you want to pause the display for some reason so other people might start to miss it if you change it. :-) Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Windowmaker on OS X Mac
On Sun, 24 Jun 2012, Rodolfo kix Garc?a wrote: I am not using OS X, but probably you should install XCode, GCC, or MacPorts to do it. Apparently it's in MacPorts, see: https://trac.macports.org/browser/trunk/dports/x11/windowmaker/Portfile (albeit not the latest version) so it's probably the easiest to try that first. After that you might try to update the portfile to the latest version or fix any errors you encounter, see how to make a local version of the port you can work on here: http://guide.macports.org/#development.local-repositories It's also in fink (but no binary since 10.5): http://pdb.finkproject.org/pdb/package.php/windowmaker But maybe unless you use X11 in a full root window on OS X, Window Maker might not be that useful because normally the Aqua WM will manage X apps. (I may be wrong though, I've never tried Window Maker on OS X.) Regards, BALATON Zoltan
Re: Includes
On Sun, 24 Jun 2012, Rodolfo García Peñas wrote: Therefore, not all the .c files have .h file. This is possible, but he main reason is because some of them are using funcs.h and Windowmaker.h to include their structs and prototypes. Of course, funcs.c and Windowmaker.c doesn't exists :-) For this reason, I think we need a plan: You may want to consider that .h files are not necessarily belong to .c files and it does not have to be a one-to-one mapping. In the object oriented paradigm .h would declare the methods or the interface of an object and the .c would contain the implementation (the actual method definitions). Thus it's fine to have internal functions defined in the .c file and also fine to split the implementation into multiple .c files while there's still only one .h file. You could also think of this as modules. The functions declared in WindowMaker.h might belong to a core module which is implemeted in multiple .c files. Of course this can be changed and fixed if this is not anymore the case but the point is that it should follow some logic and not just make every .c file have a .h file declaring every funtion. That's why we need a plan and have to think about what are the modules that need a .h file first :-) Regards, BALATON Zoltan
Re: Patches: Various ways of easily relaunching applications
On Fri, 30 Mar 2012, Iain Patterson wrote: These patches implement three variations of what I consider to be a fairly useful feature of Windows 7 (of all things), namely the ability to middle click on a taskbar entry and have a new instance of that application be launched. So for example if you middle click on Explorer a new Explorer window pops up. How does this relate to the existing Ctrl + Launch from the Dock or Clip functionality? Just asking in case you didn't know about that. To me it looks similar but I haven't used Windows 7 so it may be different. The equivalent of the taskbar (if not the Clip set to attract icons) may be the undocked appicons so extending Ctrl + Launch functionality to these could be more fitting to Window Maker in my opinion. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Launch WPrefs by default via the primary dock button (was: Defaul dockapps on distros)
On Sat, 18 Feb 2012, Paul Seelig wrote: On 02/18/2012 12:23 PM, Kamil Rytarowski wrote: - change the behaviour of the About GNUStep button, and pick there the configuration (one free space for a dock) +1 Using the primary dock button for launching WPrefs shold definitely be the overall default already on source code level! This is thwe way it is also configured for the Window Maker Live CD. Unfortunately i don't speak C, so i can't send in any usable patch myself. If we want to be true to the NeXT interface then the first icon in the dock should bring up a file manager (like the Finder icon in OS X). The Preferences.app was opened by the clock/calendar icon (which is not that intuitive but this is how NeXT used to be). In OS X the calendar icon more intuitively brings up iCal and the preferences utility has a separate icon on the dock. Since Window Maker aims to recreate the NeXT user interface these could be considered before redefining the meaning of these icons in the dock. About including default dock apps in distros, I think it can be tricky because everyone prefers different dockapps. (For example, I'd add wmnd to control network interfaces.) If some default set is included then they should be Suggests instead of Requires if the packaging system supports that (rpm and dpkg does) because they are really optional. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
