Re: wmaker: fix stacking order of dock and fullscreen

[Yury Tarasievich]

I didn't yet give 0.95.8 a try, but I, too, am 
using the possibility of having the windowed app 
in front of the full-screen one, like in Mplayer 
uses full-screen and then I do a "switch to" the 
email client ("bring it in front of the 
Mplayer") and "back". Would someone please look 
into it?


-Yury

On 17/03/17 12:24, Bjørn Mork wrote:

Michael Shigorin  writes:

...

Well 0.95.8 broke my *very* convenient use case of having a
fullscreen xterm with mail/build/whatever and a casual another
non-fullscreen one on top of it, or switching between two
fullscreen windows (yeah, those inventive users!).

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: XKB layouts management gone?

[Yury Tarasievich]

Month passed... I've discovered this reply in 
the spam bin. Yet then I've re-pulled and 
re-compiled from scratch, and the problem sort 
of disappeared. I didn't research this after 
that. Glitch of updating the system or something.


Thanks.

On 25/09/16 08:15, Josip Deanovic wrote:

On Sunday 2016-09-25 07:27:51 Yury Tarasievich wrote:

Thanks, Josip.

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: XKB layouts management gone?

[Yury Tarasievich]

Well, never mind. I've just 
recompiled/reinstalled with the already 
configured sourced, and things went back to normal.
It was just the windowmaker 0.95.7 in slackware 
14.2, compiled/packaged without the 
--enable-modelock option.
The version in prefs start panel looked recent 
after install, so I didn't bother to reinstall 
from source.


-Yury

On 25/09/16 07:27, Yury Tarasievich wrote:

Thanks, Josip.

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: XKB layouts management gone?

[Yury Tarasievich]

Thanks, Josip.

But I'm compiling the git checkouts with this 
option enabled and use its visual indicator 
since, what, 2009?


And yesterday I've suddenly noticed that I have 
to constantly cycle the layouts after switching 
between the windows.


And there's no indicator. And no means for the 
feature's activation in Prefs.app.


Even supposing WindowMaker lost the setting 
somehow. I've just checked in all the 
Prefs.app's tabs, content grouping there being 
what it is.
I still can't see the checkbox for this setting 
(I remember only it was a checkbox, one in a 
group of three; not the specific tab, however; 
and it had fairly obvious name previously).


Nothing in .xsession-errors. I wasn't even 
touching anything w/r to the xkb data handling 
recently, and the switching works, anyway.


From the tail of my config.log:
<...>
#define XKB_MODELOCK 1
<...>

-Yury

On 24/09/16 22:46, Josip Deanovic wrote:
...

Hi Yury

As far as I know this option is still available and
you need to enable it during compile time like always.

I think that the option is called "--enable-modelock".




--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.7-39-gcb1760d

[Yury Tarasievich]

On 08/02/16 18:56, Doug Torrance wrote:

On 01/24/2016 11:54 AM, Yury Tarasievich wrote:

If I get this right, this would give us a
possibility to fill any element's background
with a (tiled) pixmap?


Sorry for the late reply!  I just noticed this.

It was actually already possible by manually
editing config files, but now you can use WPrefs
as well.


No problem, thank you. I've been actually using 
the option of manual editing for quite a while 
:) Nice to have this in WPrefs, too.


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: Bug#813837: wmaker: autostart script runs twice

[Yury Tarasievich]

I seem to remember that wmaker restarting the 
session could cause the similar effect-- of 
autostart 'running more than once'.


Is there a programmatic signal to restart a 
wmaker's session?


-Yury

On 07/02/16 23:37, Doug Torrance wrote:

I'm forwarding a bug report from the Debian Window Maker package:

On 02/05/2016 02:13 PM, nefedov wrote:

Package: wmaker
Version: 0.95.7-3
Severity: normal

  My autostart script (~/GNUstep/Library/WindowMaker/autostart)
  runs twice. To test I put the following line in script:

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: Screenshot submenu

[Yury Tarasievich]

Missed this thread when it was hot, but...

The *only* issue I would *not* want to get with 
such a modification would be the mod 'snatching' 
somehow the PrtScr shortcut I (or anyone else) 
already use for calling on (almost) the same 
functionality.


Regarding the menu item itself: go for it. It'll 
work adequately in, like, 99% of use cases.


The person using the wmaker will either use the 
mod or roll their own, after which the 
much-lauded openness to changes would be of no 
interest (in this corner).


-Yury

On 01/26/2016 10:04 PM, PERROTON, Laurent wrote:

The command could be included in the default
menu. If the program is not installed, it will

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.7-39-gcb1760d

[Yury Tarasievich]

If I get this right, this would give us a 
possibility to fill any element's background 
with a (tiled) pixmap?


-Yury

On 01/24/2016 04:53 PM, crmafra wrote:
...

http://repo.or.cz/wmaker-crm.git/commit/cb1760dc0bdf89c67c62a76ab1e8e6686775a0c8

commit cb1760dc0bdf89c67c62a76ab1e8e6686775a0c8
Author: Doug Torrance 
Date:   Sun Jan 24 01:32:29 2016 -0500

 WPrefs: Add support for fpixmap ("fillscale") texture.

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 2/2] Enable usermenu

[Yury Tarasievich]

Thank you, Josip, Zoltan,

I think I've got your meaning now. Of course, 
I've never been a heavy *STEP user, so those 
extra menus which one app here, in WM, would 
have, and others would not, does not hold such 
an appeal. On the other hand, an extra 
functionality for the same money won't hurt, 
would it?


Another thought: could those app menus be 
automatically picked by WM from, e.g. GNUstep 
installation?


-Yury

On 08/26/2015 01:40 PM, BALATON Zoltan wrote:
...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 2/2] Enable usermenu

[Yury Tarasievich]

On 08/27/2015 12:07 AM, Josip Deanovic wrote:

On Wednesday 2015-08-26 19:59:04 Yury Tarasievich wrote:

Another thought: could those app menus be
automatically picked by WM from, e.g. GNUstep
installation?


Are we talking about usermenu or appmenu?


I mean those app-usermenus we were talking about 
just now. Are there any useful usermenus-related 
resources for WM to pick up from GNUstep 
installation? Or is this a completely 
stand-alone-from-anything-else feature?


-Yury


usermenu is a feature of the windowmaker which enables sending
a configurable keyboard events to specified window while appmenu
is a menu programmed into an application itself (check wterm
source and its -wm option for more info).



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 2/2] Enable usermenu

[Yury Tarasievich]

Thank you so very much. I understand now how it 
functions.


Not all clear yet, though:

Call me dim, but this functionality is useful 
for what use scenario?


Like, *when* might I want a menu popping up on 
every focus change? (I assume this is explicit 
switch of focus, not 
auto-grabbing-focus-from-passing-mouse).


If somebody could offer some advice on this, please?

-Yury

On 08/25/2015 06:39 PM, Josip Deanovic wrote:
...

3. Run kcalc and every time it is focused with the pointer a menu should
appear. Selecting a option from the menu will send the specified
keyboard event to the kcalc window (kcalc.Kcalc window to be exact).



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 2/2] Enable usermenu

[Yury Tarasievich]

Guys, terribly sorry for the ignorance, but I 
somehow can't figure out this new (old?) menu thing?


It is named window class.menu and has to 
reside in a specific location, that much I've got.


Now, tell me, please, when/how is this new menu 
activated; is it superceding the global menu? 
So, e.g., 'maximize' from global menu item must 
be added by hand into every such app menu?


Can't play with patching/compiling right now.

-Yury

On 08/25/2015 08:15 PM, Amadeusz Sławiński wrote:
...


--
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

[Yury Tarasievich]

I'd like to chime in with following notes and 
queries:


1) Ctrl+DblClick is rather weird-looking 
feature, way out of what's commonly expected in 
2015.


Not a good usability, too. One time you open the 
item by a single-click, and in another context 
(suddenly) you have to use something completely 
different? Your penguin may explode.


I just checked -- yes, even with 'single click 
activation' you still have to use DblClick with 
Ctrl. That's why I generally open instances off 
the popup menu and shun Dock/Clip completely -- 
the menu functions in an expected manner.


2) How problematic would it be to add 
_additional_ Click/DblClick for _indiscriminate_ 
opening of an instance?


2.1) Or add it as an alternative?

2.2) Without breaking the things for guys used 
to Ctrl+DblClick behaviour, too, of course.


-Yury

On 06/21/2015 09:30 PM, Josip Deanovic wrote:

Quoting message written on Sunday 2015-06-21 20:12:23:

...

On my side I can re-run a new instance of an application by doing
Ctrl+DblClick which is an official feature. Do we really need to add
an ugly hack to implement an unexpected side effect, which would be
configured through an option that is totally unrelated to the behaviour
controlled?


But it worked in 0.95.3 and I am inclined to believe that author wanted
it that way rather than the doubleclick was implemented by mistake.
If it actually was a mistake it is still something users saw as a feature.

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

LOCALEDIR on mixed 64/32 bit installation

[Yury Tarasievich]

Just noticed:
The configuration on a 64-bit system which has 
32-bit libraries additionally installed (e.g., 
slackware 14.1 with compat32 package) leads to 
compilation with locale directory parameter set 
to 32-bit instance, like in the following fragment:


gcc ... -DLOCALEDIR=\/usr/lib/locale\ ...

On my system the compat32 is packaged from the 
same distro version (32-bit) libs, so nothing 
bad happens, but I still think this behaviour is 
technically incorrect.


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 2/3] Renamed apercu to minipreview in the source code

[Yury Tarasievich]

Thank you very much :))

-Yury

On 12/31/2014 02:11 PM, Carlos R. Mafra wrote:
...

I fixed the commit logs accordingly and pushed the changes to the repo.



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

LibreOffice 3.6.7.2 misfunctioning in Wmaker

[Yury Tarasievich]

The Writer app from LibreOffice 3.6.7.2/amd64 is 
mismanaged by #next Wmaker (for some time now, 
more than a month, but definitely not three months).


That same LO installation worked fine before. It 
works fine in Fluxbox. LO 4.* series works fine.


What happens is LO somehow sees and uses some 
different screen estate from what really (by the 
WM visuals) it is allowed to use.


If LO was started unmaximised and then I 
maximise the window, I get max'ed wmaker window 
and LO using old geometry (screenshot 1).


If I manually resize max'ed window down, e.g., 
by X, I can get LO window cut from left and some 
of menus not showing at all (screenshot 2).


All this is quite annoying. I didn't see 
anything like it for like 10 years, when Java 
apps mis-behaved same way (in WMaker?). The 
.xsession-errors shows nothing.


Could something be done? How much of WM 
functionality will I loose if I revert to the 
last WM release? I can't make the switch to LO 
4.* right now.


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

LibreOffice 3.6.7.2 misfunctioning in Wmaker (screenshots)

[Yury Tarasievich]

Forgot the screenshots, sorry.

-Yury

Re: few suggestions on UI of Appearance.app and Wmaker

[Yury Tarasievich]

On 12/23/2014 02:00 AM, Christophe wrote:

- Yury Tarasievich yury.tarasiev...@gmail.com a écrit :

This action variant does not consider anything
but just unmax'es the window (visibly changing
only the status in menu, yes).


I tried to avoid any confusion here, because I think most people do not know there is a 
maximised state, that's just a computer thing. Unmaximized would means it 
has returned to its previous state, which is not what this option does; so I choose this string 
instead to try to avoid any misunderstanding. But that's still open to discussion, of course.


Non-maximised, then? Or ...takes away 
maximised flag, or ...gives unmaximised status?

In fact, any sort of active action :) verb would do.

...considers... (and any synonym) isn't an 
action, and who's doing the considering, anyway?


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: few suggestions on UI of Appearance.app and Wmaker

[Yury Tarasievich]

On 12/21/2014 07:03 PM, Christophe CURIS wrote:


...makes the window unmaximized

...


I am proposing the following patch. I put your name on the commit
because I think it is worth keeping the name of the person who made
the effort to participate.


Thank you very much. :)
You could've keep the 3rd string as proposed, 
too, though. :)
This action variant does not consider anything 
but just unmax'es the window (visibly changing 
only the status in menu, yes).


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 5/6] WPrefs: add an image to represent the window in the Window Placement frame

[Yury Tarasievich]

Very nice touch, by the way. I suppose it might 
be possible to draw something in that preview 
windowlet there, for cases when apercuses are 
not off?


-Yury

On 12/21/2014 08:13 PM, Christophe CURIS wrote:

The original square box did not look like anything, by using an image that
looks like a small window it is more clear to users what it represents.

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH (dockapps)] Add wmcdplay information for dockapps webpage.

[Yury Tarasievich]

Doug, please explain to git noobs here, what do 
we do to get all these nice changes you make to 
dockapps? Is all this being put into wmaker's repo?


Yury

On 12/18/2014 10:41 PM, Doug Torrance wrote:
...

diff --git a/dockapps.db.in b/dockapps.db.in

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: Window Maker as the official window manager of the GNU operating system

[Yury Tarasievich]

On 11/21/2014 07:49 PM, Alexey I. Froloff wrote:

On Fri, Nov 21, 2014 at 02:15:36PM -0200, Bruno Félix Rezende Ribeiro wrote:

I'd say that if you want to use Window Maker, then use it.


We'd rather fork it.

...

The GNU project is really sorry that you've declined to cooperate,
because our policy is to avoid a fork by all means.  Now,
unfortunately, we have no choice.


Are you trying to threaten us, or what?  Who are you?  You did
nothing for the Window Maker.  Your GNU thing forgot about it

...

Well, the GNU guys (or any other guys) are 
perfectly at will to take the actual work (which 
is indeed improvement over historical 0.92) and 
fork it, etc., providing the license is kept.


Don't understand this promptness to move to GNU, 
too. Where's the fire?


However, I see no problem at all with fork, if 
Carlos and other contributors would continue to 
improve this here project.


And I perfectly understand Carlos (and other 
contributors) reluctance to change even one iota 
in their current work setup for somewhat dubious 
gain of being 'GNU approved'. BTW, what's this 
about the term 'open source' disallowed or smth.?


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

.authName

[Yury Tarasievich]

BTW, guys, I think I've just hit the Libreoffice's

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=76742

with October's git commits (between September 25 
and OCtober 14, I think).


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

appicon icons

[Yury Tarasievich]

Hi guys,

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.

Yury

P.S. I work without dock because I don't like 
spending the screen on gnustep icon doing 
nothing productive, and, having no launchbar or 
something, I prefer having only miniwindows 
icons, anyway.



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 2/2] NEWS: Add note about dragging maximized windows.

[Yury Tarasievich]

On 09/25/2014 06:30 AM, Doug Torrance wrote:
...

+  in many modern desktop enviroments, e.g., GNOME, Cinnamon, and Unity.  A


I'd change the wording to in desktop 
environments like GNOME, Cinnamon, and Unity.


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 1/4] wmaker: Clear maximized flag of a maximized window when moved.

[Yury Tarasievich]

On 09/22/2014 10:16 AM, Iain Patterson wrote:
...

   Having thought some more about it I propose
that in WPrefs the setting be shown as a heading
Moving a maximized window followed by a
dropdown with three settings: behaves normally
(current default), restores original size
(shrink on move) and commits new dimensions
(clear flags).

...
Why not name the 3rd option becomes unmaximised 
(status/flag changed only)?



completeness we might now add it with a fourth
description along the lines of is prevented.


Seems like a very sane 4th option. Name it on 
the lines of is forbidden, though.


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH v3] NEWS: Add note about window snapping.

[Yury Tarasievich]

On 09/22/2014 10:20 AM, Iain Patterson wrote:
...

   Windows gives a visual hint when a window is
going to snap and resize.  One could argue that
the hint is subtle and too slow to appear but it
is there.


MS developers may shoehorn their captive 
audience into all kinds of behaviour and get 
away with it. Here, not so. But if the option is 
named with care and kept away from the first 
row, why not, after all?



   As long as the window doesn't literally
resize without warning the feature could work.


That's some legalese. :)

Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 1/4] wmaker: Clear maximized flag of a maximized window when moved.

[Yury Tarasievich]

On 09/22/2014 11:38 AM, Iain Patterson wrote:
...

   Perhaps is prevented would be better.
Forbidden implies you're being naughty if you
do rather than you literally can't.


Well, to me the ideal name of the option is 
the end result of its activation. So, 
respectively, window will be considered 
unmaximised and window will not move.


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 3/4] wmaker: Moving unmaximizes windows.

[Yury Tarasievich]

I didn't even download these changes, yet, but 
I've thought that going 'unmaximised' would NOT 
suppose changing the size as well, just the status?


Yury

On 09/21/2014 12:55 PM, Carlos R. Mafra wrote:

On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:

If a user moves a window which is currently maximized, the current behavior is

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 3/4] wmaker: Moving unmaximizes windows.

[Yury Tarasievich]

I didn't even download these changes, yet, but 
I'd've thought that going 'unmaximised' would 
NOT suppose changing the size as well, just the 
status?


Yury

On 09/21/2014 12:55 PM, Carlos R. Mafra wrote:

On Sat, 20 Sep 2014 at 22:56:24 -0500, Doug Torrance wrote:

If a user moves a window which is currently maximized, the current behavior is

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 1/4] wmaker: Clear maximized flag of a maximized window when moved.

[Yury Tarasievich]

*Moving* maximised windows is not a problem, 
it's maximised window (suddenly) *changing size* 
when moved that's a problem. I only moved it, what?


I foresee folks developing certain subconscious 
fear of moving the Wmaker's windows in general - 
what if it'll change its size? Perceptionally, 
what's the distinction between moving the max'ed 
and the unmax'ed windows? None.


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH v3] NEWS: Add note about window snapping.

[Yury Tarasievich]

Wait, does this change the window size when 
move's in progress, too?
Then it's not snapping at all, and the term 
used is very confusing.
More precisely, it's something like 
half-maximise when edge is hit or half-fill 
when edge-snapped.
Snap is only the intermediate result here, 
triggering the final result.


Yury

On 09/22/2014 05:02 AM, Doug Torrance wrote:

+You can now snap a window, i.e., maximize it to the left or right half of the
+screen, by dragging it to that side.  It is enabled by setting

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH v3] NEWS: Add note about window snapping.

[Yury Tarasievich]

On 09/22/2014 08:18 AM, Torrance, Douglas wrote:

On 09/22/2014 12:06 AM, Yury Tarasievich wrote:

...

Snap is only the intermediate result here, triggering the final result.


The size of the window isn't changed until after the move is completed.


So it's even worse, on two accounts.

First, you get your window size changed 
*unexpectedly*. Who pays to attention to those 
end boxes, really? Should one treat the 
half-visible end boxes as something, examining 
which is obligatory for the successful operation 
completion? Those boxes are just (useful) hints!


Second, I wouldn't want a MS-bashing session 
develop here, but really, their interface 
contributions (terminology included) *may* 
happen to be just silly, and replicating them in 
the window system which had and used correct 
snap for ages is ..., well, not so clever, too. :)


Yury


While moving the window, only a transparent frame is shown showing the
future position/geometry of the window if the user chooses to complete
the snap.  The term is borrowed from (gulp) Windows [1].

[1] http://windows.microsoft.com/en-us/windows7/products/features/snap




--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 1/5] wmaker: fix focused window list order

[Yury Tarasievich]

I got confused -- will Alt+Tab retain its 
current rules of window shuffling, or not?


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 1/5] wmaker: fix focused window list order

[Yury Tarasievich]

On 09/20/2014 09:24 PM, Carlos R. Mafra wrote:

On Sat, 20 Sep 2014 at 21:08:34 +0300, Yury Tarasievich wrote:

I got confused -- will Alt+Tab retain its current rules of window
shuffling, or not?


Yes, the patch was already reverted.


...which was the only reasonable way out, after 
all. Thanks!


Yury



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 3/4] wmaker: Moving unmaximizes windows.

[Yury Tarasievich]

Doug,

If you're looking into windows placement and 
sizing, would you spend a moment on related, and 
somewhat annoying problemettes:


1) Windows of certain applications always get 
placed overlapping the icon strip - wxMaxima. 
Their size is never retained from the last use, 
but is set, well, not arbitrarily, there seems 
to be some logic in this, but with what rules?


2) Position of windows having height equal or 
approx. equal to the height of the screen is set 
not to Y=0, but to about 1...1.1 titlebar 
heights lower. I experience this with Libreoffice.


I believe I've tried all reasonable placement 
schemes and edge resistance/attractance 
combinations. Now it is 'automatic' with 'edge 
resistance'.


Yury

On 09/21/2014 06:56 AM, Doug Torrance wrote:

If a user moves a window which is currently maximized, the current behavior is

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: application icons

[Yury Tarasievich]

It's more complicated than that, actually.

Further in the message there's a link to 
screenshot showcasing wmaker's handling of icons 
for the complex applications. On the shot, there 
are icons for:


* LibreOffice's StartCenter: 5th icon from top, 
window class as reported by Wmaker: 
VCLSalFrame.DocumentWindow.libreoffice-startcenter


* LibreOffice's Writer: 7th icon from top, 
window class: 
VCLSalFrame.DocumentWindow.LibreOffice 3.6


* miniwindows for writer documents which were 
open respectively 1st and 2nd in the LibreOffice 
session: 2nd and 1st icons from the bottom. 
These both are LO Writer windows with documents 
open, but their window classes are different: 
VCLSalFrame.DocumentWindow.libreoffice-startcenter 
(2nd from bottom) 
VCLSalFrame.DocumentWindow.LibreOffice 3.6 
(1st from bottom).


In WMWindowAttributes, there are two entries, as 
expected.


http://s1311.photobucket.com/user/georgius70/media/20140825_wmaker_different_libreoffice_icons_zpsd5af77bb.jpg.html

***

The issues are:

1) If I change the *appicon* for 
VCLSalFrame.DocumentWindow.LibreOffice 3.6, 
the miniwindow icon (of the same class) stays as 
it was. Conversely, if I change the miniwindow 
icon, the app icon changes, too.


2) For some time, LibreOffice in-built icons 
used by default for miniwindows are rendered 
with errors, as seen on pic, the 1st icon from 
bottom, at least in 3.6 series of LO.


***

The suggestions:

1) Is it possible to introduce handling for 
miniwindows icons separated from respective app 
icons? These are already treated specially in 
wmaker, after all, and icons for them are 
already being processed in slightly different 
way (different dialogs, different behaviour).


2) Is it possible to introduce handling of the 
miniwindows representations on base of window 
class AND window title? By their nature 
miniwindows are, as like as not, related to the 
data files instances.


So, as to keep compatibility, why not have 
WMWindowAttributes entries looking like 
(comments explicate the concept some more)


/* the miniwindow for the fancy.odt is iconed 
with fancy icon.png */

  VCLSalFrame.DocumentWindow.LibreOffice 3.6 = {
/* in the respective dialog, an additional 
checkbox would be required */

IsMiniWindow = Yes;
/* additional field for the window title would 
be required, too */
/* regexes or at least shell patterns would be 
preferrable, if at all doable */

WindowTitle = fancydocument.odt - *;
AlwaysUserIcon = Yes;
Icon = fancy icon.png;
  };

/* the miniwindows for all other document titles 
are iconed with openofficeorg3-writer.png */

  VCLSalFrame.DocumentWindow.LibreOffice 3.6 = {
IsMiniWindow = Yes;
/* empty/blanks-only field value considered to 
be all-matching */

WindowTitle = ;
AlwaysUserIcon = Yes;
Icon = fancy icon.png;
  };

/* traditional format, implicitly regarded as 
pertaining to app icons only, not miniwindows */

  VCLSalFrame.DocumentWindow.LibreOffice 3.6 = {
AlwaysUserIcon = Yes;
Icon = openofficeorg3-writer.png;
  };


***

Well, what do you think? BTW, I do not consider 
an attention to the icons handling to be 
misdirected. E.g., personally, I'm relying quite 
heavily on the visual cues from app and 
miniwindow icons in my daily work.


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

application icons, again

[Yury Tarasievich]

Hi all,

On a fairly recent 64-bit system (slackware 
14.1) a couple of 32-bit apps do not show their 
application icons: Thunderbird and Firefox, also 
the FF's addon DownThemAll which works in a 
separate window. For DownThemAll I don't think 
there's even a separate icon file.


This problem is definitely related to the system 
(Xorg?) version. There was no such problem on ~2 
yrs old 64-bit system (slackware 13.37) which 
sits on a neighbouring partition (my homedir is 
shared).


In .xsession-errors there are some messages 
about X errors, catched in WindowMaker.
I have cleared the icons cache, FWIW. 
WindowMaker is at #next.


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

application icons

[Yury Tarasievich]

Hi all,

The application icon and the related application 
miniwindow icon have to be set separately (if 
windowmaker can't retrieve the icon from the 
running app itself). Is this an intended behaviour?


Yury


--
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

[Yury Tarasievich]

On 06/09/2014 09:53 AM, Josip Deanovic wrote:

Quoting message written on Monday 2014-06-09 08:39:59 by Yury:



Yury, it looks to me that you understand the problem quite
well and the problem is: starting from 0.95.4 if you have
dragged some app icon to the wmdock you would need to use
CTRL + double click or CTRL + single click (in case you are
using the SingleClickLaunch = YES option) to launch
additional instances of the application represented by the
app icon in the wmdock.


Yes, yes, but hadn't this behaviour been there 
since ever? You mention the 0.95.4 as a 
milestone for this change, and I fairly well 
remember having to right click\Launch to get 
an additional instances of xterm as far back as 
0.92/0.93, and I definitely remember this wmaker 
behaviour in 2009. So I'm wondering, might you 
be talking about something (subtly) different?


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.


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?


Yury


--
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

[Yury Tarasievich]

And that's the subtle difference: I'm talking 
about the app icons auto-created by wmaker (I 
think I've used the dragged-to-dock icons like 
once or twice).


That's the bug, of course, such difference 
shouldn't be there at all.


On 06/09/2014 11:09 AM, Josip Deanovic wrote:
...

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?


I am disabling app icon for every single application
I use so app icons don't really bother me because I
see them only once per application (first time I launch
an application).


Disabling every app icon as they appear doesn't 
look like a productive scenario to me. :)


Yury


--
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

[Yury Tarasievich]

If I have no Dock and no Clip active, app icons 
are created anyway (couple of weeks old #next).
These app icons are sort of skeleton ones -- 
they react only to double-click (although I have 
single-click activation in config), and their 
only reaction is self-highlighting. 
Ctrl-double-click works, however. :)


And disabling the app icon individually for 
anything I might start does not seem a viable 
solution.
It is good onloy for the likes of Firefox's 
flash container or LibreOffice java instance.


Yury

On 06/09/2014 12:47 PM, BALATON Zoltan wrote:
...

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.



--
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

[Yury Tarasievich]

I don't understand Josip's problem. Would 
someone clarify? The 
more-than-one-instance-unlaunchable-by-simple-action 
icons in Dock are there since ever. I 
definitely remember those in 0.92? (what was 
that stale version before Carlos took over?). 
And I think I can recall my initial confusion 
with 0.80? (well before Y2K).


However, the 
more-than-one-instance-unlaunchable-by-simple-action 
icons in Dock are not intuitive, indeed, and not 
practical, too -- in this Josip's quite right. I 
use single-click-activation, still, having to 
reach for the CTRL is a source of irritation 
(albeit very minor). And I had to stumble upon 
the CTRL-click combination, too, after long 
using right click\Launch.


I have a different proposition, however. How 
about enabling Wmaker to work without creating 
those app/mini icons at all?


I've been trying a similar setup for a while (no 
Dock, no Clip, miniwindows either enabled or 
disabled) and it MIGHT have its plusses, BUT 
some sort of icons is always created, messing 
the significant part of the screen space.


Yury

On 06/08/2014 11:58 PM, Josip Deanovic wrote:
...


--
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

[Yury Tarasievich]

On 06/07/2014 04:34 AM, BALATON Zoltan wrote:

On Sat, 7 Jun 2014, Josip Deanovic wrote:



docked application using double-click.



I don't mind either way (not using that option)
but isn't double click with Ctrl pressed


And there is an option of launching with single 
click, so it's double/single click, really.


I have it active on recent #next 
(0.95.5-something) and the Ctrl-click 
combination works on my system.


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] WPrefs: add expert option to disable switch panel

[Yury Tarasievich]

Oh well. Still this isn't cycling, we find 
cycling alt-tab in other platforms GUIs, all right?


Yury

On 06/05/2014 07:37 AM, David Maciejak wrote:

Enclosed the patch with lain text proposal Show switch panel when
cycling windows. and with logic changed, to amend commit
c994b65f14ad2ab872f5c1b91119d78885743cfc.



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] WPrefs: add expert option to disable switch panel

[Yury Tarasievich]

On 06/05/2014 09:19 AM, Iain Patterson wrote:

Quoth Yury Tarasievich,


Oh well. Still this isn't cycling, we find
cycling alt-tab in other platforms GUIs, all
right?


   I'm not dead set on the word cycling I just
want us to be consistent about what we do use.


Consistency is a big problem in OSS as a class, 
anyway.



   Having said that I do think that cycling is
fine because if you keep pressing FocusNextKey
you keep on iterating through the window list


To repeat myself, if you do one-off alt-tab, do 
you get cycling? In fact, you get the opposite, 
or, at least, not cycling through the initial set.


When you work with switch panel activated, you 
get additional visual element, which doesn't 
change the base logic of the action, but 
provides additional controls.


This just doesn't boil down to cycle, this is 
broader than just cycle, but then again, 
having had worked on l10n for a while, I just 
might have a somewhat different perspective on 
this...


BTW, I still remember this little change of 
logic of alt-tab behaviour was quite a source of 
confusion to me in days of transition from 
os2/win guis. These days, I rely on this feature. :)



but if you want to call that switching instead
then I won't object as long as you can convince
everyone else that it's worth changing.


Well, I won't put any additional effort into 
this worthy task.


It's sort of people problem, not argument 
problem: changes on the scale of this are 
disproportionally hard to negotiate.



   If we do change it we'll probably need
different text for the new preference because
Show switch panel when switching windows is a
bit weird.  Just Show panel... maybe?


There are lots of panels, which one do you have 
in mind? :)


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] WPrefs: add expert option to disable switch panel

[Yury Tarasievich]

On 06/04/2014 01:22 PM, Iain Patterson wrote:


   * Use the text Show switch( )panel when
cycling windows (defaulting to on) for the
patch under discussion.


Cycling is not so good. Using switchpanel you 
may switch to any of windows at once.

Let's keep the switch verb with the switchpanel.

Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] WPrefs: add expert option to disable switch panel

[Yury Tarasievich]

Alt-Tab is cycling only in one specific 
scenario (holding the Alt).
It's back-and-fro'ing between windows (Alt-Tab 
with complete release) and calls up the switch 
panel (Zoltan is right about that space there)


Anyway, the distinction isn't worth an 
additional verb, somewhat too informal at that.

Cycling? Bicycling? Recycling?

Yury

On 06/04/2014 03:17 PM, Iain Patterson wrote:

   The shortcut's purpose is to cycle windows
and this new preference controls whether or not
the above side-effect is active, so I would
argue that the term is appropriate.



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] Fix issues with alt-tab

[Yury Tarasievich]

On 05/26/2014 03:20 PM, Josip Deanovic wrote:


Most of the people probably don't even know how to turn off the
switchpanel.


...or even want to, for that matter :)

If we are talking dear memories 10+ years old, 
I'd quite like to see xview's virtual desktops 
manager in windowmaker. Possibly, with 
additional (windowmaker style) pop-uppish 
behaviour triggered by window crossing the 
desktop border. Or is there such a thing 
available already??


Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] Fix issues with alt-tab

[Yury Tarasievich]

On 05/26/2014 09:57 PM, Josip Deanovic wrote:

Quoting message written on Monday 2014-05-26 20:27:16 by Yury:

I'd quite like to see xview's virtual desktops
manager in windowmaker. Possibly, with



Are you talking about Openlook's pager?


I don't remember well what was that thingy 
called in openwin/ol[v]wm/Xview.
It had the (default) 3x3 matrix of virtual 
desktops and the windows' movement was reflected 
there live.
It looked like a pinnacle of usability w/r to 
the virtual desktops concept. Why an equivalent 
seemed never to exist in the open-source?



In 2004 I made pager for windowmaker as well as a simple icon
manager but I have planed to add some more features so that cod
was never released and still waits in archived directory for
me to get some time.

My pager doesn't look like the one I remember from Openlook, it's
actually meant to be used inside wmdock.


That 64x64 field (or even 48x48 or 32x32, eh?) 
might be not so useful, and would take an 
expensive screen estate. That's what I dislike 
in many WM-styled apps.


I'd imagine an ideal xview-like pager popping 
up only if window crosses the desktop border 
and/or when some screen edge is hit with mouse 
pointer.


BTW, the last I've looked, Xview was released at 
http://www.physionet.org/physiotools/xview/src 
(2007 source release). I couldn't compile it w/o 
lots of bother, so I didn't.


Yury


--
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

[Yury Tarasievich]

On 05/25/2014 02:29 PM, Josip Deanovic wrote:

Quoting message written on Sunday 2014-05-25 11:42:33 by Carlos R. Mafra:

I cannot apply this. Just checking the chronology of development
I don't understand how removing the above lines can fix your problem.

...

By removing those lines I was able to cycle trough the list of
windows, including shaded windows.


Is this a change of a known default behaviour of 
0.9* series, where ALT-TAB brings out a blue 
panel with all the windows to cycle through? Or 
does this map to ALT-TAB something else?



--
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

[Yury Tarasievich]

The blue panel on my system (several days old 
#next) includes shaded windows.


Yury


--
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

[Yury Tarasievich]

On 05/25/2014 05:50 PM, Josip Deanovic wrote:

Quoting message written on Sunday 2014-05-25 17:33:00:

The blue panel on my system (several days old
#next) includes shaded windows.



It does include shaded windows but if you cover shaded windows
with some normal windows you will notice that the shaded window
doesn't rise.


But it does. I've never used this shading 
feature, in any WM, so maybe I'm not reproducing 
it right.

Here's how it goes here:
xterm - right click on titlebar - select shade - 
xterm shrinks to its titlebar - select anything 
normal to put it over shaded xterm - alt+tab - 
blue panel pops up - any way of selection partly 
transparent icon of the shaded xterm works


Yury


--
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

[Yury Tarasievich]

Okay.

However, I'd really like to know, would fixing 
this break the existing alt-tab 
behaviour/switching order?


Yury

On 05/25/2014 08:02 PM, Josip Deanovic wrote:

Amadeusz


Yes, that's it.

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 0/3] Changes in NetPBM support

[Yury Tarasievich]

You have google's address, and google filters 
out some patches to its spam can.


On 04/16/2014 10:55 AM, Carlos R. Mafra wrote:


I've just found out one of the reasons why I was puzzled
by your series. I'm not seeing all the patches.



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

windows placing and sizing

[Yury Tarasievich]

Hi guys,

Please, could somebody look into an issue with 
libreoffice's document windows?


On my system it regularly happens that opening 
of the LibO (existing document) window leads to 
this window being resized less in height than 
previous LibO document window. Opening yet more 
documents I can get existing LibO document open 
in window looking like titlebar and lower 
resizing border only.


This happens in two steps - 1) document is open 
in what looks standard wmaker guess for window 
size, than 2) window is shrunk in height. If I'm 
lucky, I get subsequent windows of equal (if too 
small) height (and don't necessary have to 
resize by hand) but if I'm not lucky (reduction 
under some threshold height?), I get the 
lessened height progression.


Tried smart, cascade, auto placement. 
Wmaker is yesterday's #next.


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 1/3] move maximization size adjustments to maximization function

[Yury Tarasievich]

Should non-maximized windows respect do not 
cover... settings, too?


-Yury

On 11/23/2013 02:28 PM, Carlos R. Mafra wrote:
...

I have a maximized chrome window which does not cover the dock (on the right)
because of the do not cover dock option. When I open a new window (Ctrl+N),
this new window partially covers the dock (by around 32 pixels), so it does
no longer respect the do not cover dock option.

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH 1/3] move maximization size adjustments to maximization function

[Yury Tarasievich]

On 11/23/2013 03:09 PM, Carlos R. Mafra wrote:

On Sat, 23 Nov 2013 at 15:05:26 +0300, Yury Tarasievich wrote:

Should non-maximized windows respect do not cover... settings,
too?


I think so.

...

Well, some of them don't (as long as I remember, 
at least in 0.92), which is somewhat irritating. 
E.g., no type of placement strategy can make 
OpenOffice/LibreOffice sub-windows not to 
obscure dock/iconstrip on creation (happens 
occasionally but quite frequently).


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

apropos dragging windows across workspaces / was: Re: [PATCH] Basic WINGs theming

[Yury Tarasievich]

On 11/14/2013 02:31 PM, Iain Patterson wrote:
...

   Things which aid configurability.  We're
already very good at this.  You can, for
example, enable or disable dragging windows
across workspaces and separately enable or
disable magically creating workspaces when you
do so.  Perhaps there are other little things
which some people like and other don't.

...

I've read your comment and immediately thumbed 
through the appearance app tabs (current #next 
here). How is such window dragging activated? I 
have fond memories of XView's multi-workspaces 
control and wouldn't mind having something 
similar in wmaker.


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

a few thoughts / was: Re: [PATCH] Basic WINGs theming

[Yury Tarasievich]

Carlos: I guess it'd be better all around if you 
specified and published at least some of your 
priorities and anti-priorities. Also, set a 
procedure for cases when there's a conflict on 
what goes in and what doesn't.


I sincerely commend you picking up the project 
maintenance when there was a dire need for that. 
And I do not care much for the new features 
alltogether. However, I can see, too, how folks 
could feel uncomfortable with your stance on the 
innovation. Nobody's really challenging your 
authority and your credits. Just that you sound 
a bit authoritarian here. Again, it's not what 
you say, it's more how you say it. Why not try 
to generate more positive feelings?


***

W/r to the documentation, I'd say a potential 
user would initially want to know what one can 
do (do well) with WindowMaker.
So, to enumerate some strong sides of 
WindowMaker as I see those:

-is light-weight, instant start-up
-has usable configuration out-of-the-box
-has visual preferences editing application 
out-of-the-box
-has visualised task switching out-of-the-box, 
unlike many (all?) WMs
-has (rudimentary) visual launch list editing 
out-of-the-box (I mean launched apps leaving 
icons in dock)
-has some stylish and recognisable UI design 
elements (checkboxes, dialogs' tabs' tabs, 
radiobuttons, balloons, titlebar)


Big problems with WM:
- grossly outdated concept of paths management 
(menu editor - 'application to run' selector, 
icons/pixmap search paths )
- rough, unpolished look in some parts of the UI 
(fat scrollbars)
- no transparent background for icons? in 2013? 
(yes, it might be emulated by setting screen 
background and icon background to be the same, 
but...)
- some functional elements (theming elements 
selectors in main menu, 'run command' applet, 
window attributes inspector) feel half-done, 
even primitive


-Yury

On 11/14/2013 11:13 PM, Carlos R. Mafra wrote:
...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

action of alt-tab + left/right arrow crippled

[Yury Tarasievich]

With current #next, I can't anymore 
switch/browse throught the windows in alt-tab 
panel using left/right arrows to walk through 
the whole list. The left/right arrow takes me 
exactly one window left/right, then window gets 
switched to, and alt-tab panel disappears. Old 
behaviour was more convenient. Could it be 
brought back?


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] Basic WINGs theming

[Yury Tarasievich]

On 11/11/2013 01:09 PM, Carlos R. Mafra wrote:

On Mon, 11 Nov 2013 at  9:32:04 +0300, Yury Tarasievich wrote:

...

So I'd say there's an *urgent* need for some kind of contribution
rejection procedure. Something like following: (a) Carlos (or
anybody) with his PM's hat on has the first (immediate) say on what
is *not* going in *right now*. (b) However, there also must be an
(almost immediate) request for comments going into the list,
formal-like. (c) If the request gathers no evidence supporting the
innovation, everything stays as it was. (d) Otherwise, steps are
taken etc.

...

So in this case, despite the patch being OK I felt
the need to stop the idea. Keep the WINGs widgets as simple as

...

But given the reaction, I am forced to accept the patch. There
has even been a suggestion to fork wmaker! And perhaps I'm being
too conservative, so it will be OK in the end. But in any case,
if the repository was only mine the patch would not go in.

So the above situation corresponds to your steps a) - d) above.


Not exactly, as I see it. There was no formal 
rejection (was there?), no issuing the formal 
RRFC (Rejection Request for Comments), and so 
the ensuing discussion was mostly heated by hurt 
feelings in the unclear context.


I believe it's just this lack of a bit of formal 
procedure which made way for the unpleasantness. 
(And of course the (c) step must generate some 
definitely positive support, not lazy lack of 
opposition).


***

Having said that, the code bloat is bad, but the 
look artificially left back in the 20 years 
ago epoch might be not-so-good, too. About the 
only *visual* feature of the *WINGs* I like are 
those clever checkboxes; radiobuttons are not 
bad. Overall, the *visual* impression isn't so 
much of aged product, as of unpolished, 
rough-from-the-workbench thing. BTW, the option 
of modifying the standard colors themselves 
would be of no relevance here, without more 
extensive rethink (of layout, geometry, 
proportions etc.).


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: [PATCH] Basic WINGs theming

[Yury Tarasievich]

I think we have the gist of the problem right 
there, in the lines quoted. I see a plain clash 
of perspectives there.


We *might* benefit from the new ideas, generated 
in the way of hobbie or otherwise.
We *would* benefit from general production going 
forward.


I won't go so far as to declare the production 
manager some sort of supreme authority. 
However, it is obvious that not every idea is 
bound to make it into the (long-existing) 
software product, for which PM is, after all, 
responsible.


So I'd say there's an *urgent* need for some 
kind of contribution rejection procedure. 
Something like following: (a) Carlos (or 
anybody) with his PM's hat on has the first 
(immediate) say on what is *not* going in *right 
now*. (b) However, there also must be an (almost 
immediate) request for comments going into the 
list, formal-like. (c) If the request gathers no 
evidence supporting the innovation, everything 
stays as it was. (d) Otherwise, steps are taken etc.


I believe this is simple enough and sufficient 
to block (or alleviate) the rise of bad feelings.


And do not bother with forks, multiply repos 
etc., that's silly. There is no enough of human 
resource here as it is.


-Yury

On 11/11/2013 02:38 AM, Rodolfo García Peñas 
(kix) wrote:

On 10/11/2013 23:32, Carlos R. Mafra wrote:

...

So, what is the problem? For me wmaker is a hobbie. I spent a lot of
time writting patches, thinking about new ideas. Sometimes I make

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: Alt+Tab and mouse

[Yury Tarasievich]

Happens even if mouse cursor isn't inside the 
blue rounded rectangle (BRR). If the cursor is, 
say, higher than BRR and off to the right, 
then window currently next in priority list 
gets pre-switched-to.


-Yury

On 11/05/2013 10:01 AM, Rodolfo García Peñas 
(kix) wrote:


Nerijus Baliunas neri...@users.sourceforge.net
escribió:

...

when Alt+Tabbing, is it possible to ignore
mouse? Sometimes mouse cursor
is in the center of the screen, and Alt+Tab
ends not where I intended to.


You move the mouse? (perhaps only a bit?) and
then wmaker detects a mouse_move event or the
problem happends without moving the mouse?



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: Fwd: WindowMaker: lost maximized status

[Yury Tarasievich]

While experts are at it, please, please, kindly 
research why wmaker doesn't consistently keep 
windows positions and doesn't honour 'do no 
cover dock/icons' settings.


The following often happens here with 0.95.5 
version: window is manually re-placed and 
re-sized, so there's an entry for it in WMState. 
However, next re-launch puts window any old how 
w/r to the previously set (and kept) position 
AND also as often as not over the dock/icons. I 
experience this with LibreOffice, for I'm in 
habit of opening many windows (of same window 
type, as far as I can tell).


'Window placement' is either 'Smart' or 'Random'.

Also, could window size be kept in WMState?

-Yury

On 10/24/2013 10:06 AM, Rodolfo García Peñas 
(kix) wrote:

...


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

Re: Default icons

[Yury Tarasievich]

I ought to comment on this:

1) Legacy icons carry the sense of tradition, 
are long-known and might be referred from 
somewhere (else). On the other hand, gain from 
removing those would be nonexistent.


Please keep.

2) WindowMaker is not (yet) so great in getting 
icons from applications (recent VirtualBox comes 
to mind). But even if it was, folks just might 
want to set their own icons for something! E.g., 
libreoffice vs. openoffice appicon set. I think 
any other WM allows for that.


Also, removing the option from WMAttributes 
would strand folks working *without* either 
dock or clip (e.g., I do, for 10+ years)


Please keep.

3) Few words on appicon functionality in 
general. Anything different from 64x64 
auto-resizes not so well, and there's no 
provision for auto-selection of subdirs in 
meta-dirs. I have both gnome/48x48 and 
hicolor/48x48 added to my dirlist. (BTW, why no 
64x64 subdirs there? Because icons from those 
often are bigger in the picture part, and mix 
badly with, e.g., icons provided by applications 
themselves, which are closer to 48x48.)


Why is the operator forced to look for icons 
only in the fixed set of dirs at all? Configs 
keep full paths.


Restarting the session throws out icons set in 
WMAttributes.


Last I looked, icons can only exist in square 
blocks, with no transparency? (Might be remedied 
almost ideally by setting repetitive background 
raster having width divisible by 64)


-Yury


On 10/19/2013 03:55 AM, Torrance, Douglas wrote:

I noticed a few things while looking at the default WMWindowAttributes.

* Many of the icons don't ship with Window Maker (e.g., ColorGNU.xpm for
Emacs), but instead are in the WindowMaker-extra tarball. (Similarly,
the Debian default WMWindowAttributes, which has mostly different icons,
references icons in the wmaker-data package, which is only suggested but
not required by the main wmaker package.)

* Many of the icons are for rarely used software in a modern system
(e.g., Netscape).

* The current version of Window Maker does a mostly great job of getting
icons from applications, and so declaring icons in WMWindowAttributes
seems unnecessary outside of things like the dock, clip, and drawers
(unless the user wants an icon theme).

At this point, leaving things the way they are seems to only be of
interest for historic purposes.  I'd like to make some changes, but I
wanted to see how people felt about the issue before I started submitted
patches.

Thanks!
Doug




--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

mod of traditional interaction?

[Yury Tarasievich]

Hi all,

I wonder, whether it would be possible/feasible 
to modify one of the aspects of the traditional 
wmaker behaviour, namely, how the launch 
action is activated.


If one has Dock active and no miniwindows 
option set, one has to launch (unhide) the 
already launched and hidden application by 
either holding Ctrl and left-clicking, or by 
calling popup menu and drag mouse, 
right-button-holding (to the launch item). 
Neither way is too handy for such an elementary 
operation (requires two hands or motion).


Meanwhile, obvious actions of left-click and 
double-left-click are wasted, doing nothing 
useful (highlighting the dock icon).


So, could the call sequence for the unhide 
action be modded to accept simple left-click, 
too? Shouldn't be too complicated to check for 
the related app being already launched, should it?


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

trivial Dock questions

[Yury Tarasievich]

After a long time of using wmaker without either 
Dock or Clip, I decided to give Dock (and 
Drawers) a try today. Several trivial/silly 
questions arose:


1) How do I make icons for apps launched from 
menu to appear in line with Dock icons?


2) How do I hide Dock icon (glowing gnustep), or 
has it to be always visible (if only to carry 
add drawer in its context menu)?

Which leads to sub-questions:

2a) Drawers are created only from context menu 
of Dock icons, aren't they?


2b) Alternatively, can Dock icon be 
replaced/overriden/painted-over by app with 
functional icon (like PClock)?


3) How does Normal Dock position differ from 
Always on top and Auto raise and lower, 
besides the obvious aspect of being covered by 
windows or not? What does auto raise/lower 
actually do?


-Yury


--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.

the code for docked app icon setting?

[Yury Tarasievich]

Hello all,

Could someone point me to the code drawing 
(re-drawing) icon for the docked app?
I have set several applications with icons of my 
choice, however, when something happens in this 
apps, the custom icon gets ignored (the default, 
in-app, icon being drawn).


The most obvious example is LibreOffice, for 
which I have set two icons, for main (launching) 
window, and for writer window. The setting /are/ 
present in the WM config.


After switch of the behaviour occurs, I can 
re-set the icon for the soffice.Soffice docked 
app window, but every new click on new 
document, causing the opening of the swriter 
window, which has 
VCLSalFrame.libreoffice-startcenter 
specification, causes also the docked app icon 
to revert to the in-app one.


Also, such behaviour switch does /not/ happen 
/always/, but only after something triggers the 
switch. E.g., wine app launch seems to trigger 
it almost surely.


I'm using the build from the latest available 
git source.


Alternatively, and if humanly possible, I'd like 
to see that fixed. :)


Yury

P.S. As a side note, is it possible to have NO 
icons at all, no dock, no clip, no miniwindows? 
I can't find the combination of options for this.



--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.