On Thu, 29 Nov 2012, Rodolfo Garc?a Pe?as (kix) wrote:
Yes, you are right. We have four options:
1. ignore flag + file set
2. no ignore flag + file set
3. ignore flag + no file set
4. no ignore flag + no file set
Option 1 is clear, we provide a new icon and ignore the supplied icon by the
client.
Option 4 is clear, we use the client supplied icon and the icon provided is
not used.
But, what about options 2 and 3?
Option 3 is fairly clear too. If there is no user set icon you either
ignore the Ignore flag (bacause it makes no sense) or you may use default
app icon to override the icon window but I'm not sure how useful is that.
For option 2 I already said what I think should happen: use client
supplied icon _window_ or user supplied icon otherwise.
If we provide icon, should the flag ignored?
No, there's a reason why this flag is there. If it could be ignored there
would not be such a flag.
If we check the flag, should the file ignored?
No, the flag says AlwaysUserIcon. (That is ignore the client supplied
icons of any sorts and always use the icon file instead.)
Should we can remove the check? is the work done by the text field? If the
text is empty, should the icon provided by the client used?
But why should we change anything? Could you just make everything do the
same that it used to do before you've started changing it? Your patches
were meant to be clean up so they should preserve functionality and not
change behaviour. Or did I get that wrong? Was there a problem you've
tried to fix other than cleaning up code?
IMO we are doing something wrong with these applications (like xfig). Why
these applications have that behaviour? Xfig don't use title in the
miniwindow, sets their own icon,...
I think it is because the Ignore client supplied icon flag is broken and
not used even if it's set in WMWindowAttributes. Since xfig provides an
icon window it will override the icon even when the Ignore flag is set (or
even if the AlwaysUserIcon flag is set in the config because the checkbox
in the GUI is also detached from what's in the config file).
Again, if we remove these lines in create_for_wwindow (icon.c) xfig runs like
other applications. IMHO, these lines should be removed:
121 if (wwin->wm_hints && (wwin->wm_hints->flags & IconWindowHint)) {
122 if (wwin->client_win == wwin->main_window) {
123 WApplication *wapp;
124 /* do not let miniwindow steal app-icon's icon window
*/
125 wapp = wApplicationOf(wwin->client_win);
126 if (!wapp || wapp->app_icon == NULL)
127 icon->icon_win = wwin->wm_hints->icon_window;
128 } else {
129 icon->icon_win = wwin->wm_hints->icon_window;
130 }
131 }
Try it, and you will see that xfig has a common behaviour. The application
has icon, the title,... These lines override the common icon management.
But this breaks the wmicontest test case I've sent earlier and probably
also dockapps which need to have an icon window.
Probably we should check the icon behaviour to see if the current code
includes the idea of these lines, but, IMO this lines breaks the flow for
icon management, creating a shortcut with a different flow and should be
removed.
I don't get this. Are you trying to get rid of a special case based only
on aesthetic reasons? There is a reason that this special case is there
(as stated in the comment) so it's needed even if it's not nice to have it
there. You could move it elsewhere but just deleting it would break
something.
Again, thanks a lot for your comments. Please, try the patches, I think now
is better.
I've tried them and it does not seem better to me. Actually, it got worse.
Try to do the test sequence with xcalc. With current next branch if
there's nothing in the config it has no app icon (uses the default icon)
only the miniwindow has an icon. Then the icon from the cache is still
saved and the Ignore option checked wrongly mismatching the config file.
I gave up at this point.
Regards,
BALATON Zoltan
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
