Github

[Roman Dobosz]

Hi.

I know, that it was already discussed couple years ago, but I'd like
to revisit the current state.

For wmaker related development we now have several repositories:
- main one[1]
- one big repository for dockapps[2]
- repository for webpage[3]
- repository for dockapps.net[4]

As for bugtracker we have none, just this mailing list.

While I'm fine with sending patches to the mailing list, in my
professional (but also private) activities I'm also using other tools
for software development and I must say, that having ability to
prepare a patch, push it to gh, and prepare PR is very convenient.

I believe Douglas created window-maker organization on github
already, which could be a good opportunity for moving the code from
repo.or.cz.

As for values of such move, we could benefit of:

- having broader audience - github is currently largest hosting for
opensource projects, so it would be easy to find wmaker project for
creating an issue, submit a patch, review proposed patch
- Issue tracker
- code review system
- releases can be automatically generated
- optionally, lots of external tools which we could use (like for
example Travis, which could run some tests [oh wait, we have only
two ;P], or just build wmaker to catch up compilation errors)

What do people think?


[1] http://repo.or.cz/w/wmaker-crm.git
[2] https://github.com/window-maker/dockapps
[3] https://github.com/window-maker/window-maker.github.io
[4] https://github.com/window-maker/dockapps/tree/gh-pages

--
-^- _ something is grinding the emptiness:
_ /O)_\// Velvet Acid Christ - Collapsed
(_(|__(_(_) grf.

[Carlos R. Mafra]

Forget about moving wmaker out of repo.or.cz. This is not going to happen.

I have the opinion that patches should be sent to the mailing list.

Reading patches in the browser is not productive, sending comments in
the browser is not productive. I strongly oppose this for wmaker.

[Rodolfo García Peñas]

Hi,

We had this discussion some years ago:

https://www.mail-archive.com/wmake...@lists.windowmaker.org/msg03980.html

This project is not democratic, and for that reason I stopeed to sent patches. I creaed a fork to re-write all the low level stuff (awmaker) and now I sent only patches to wmaker-crm related to libs and other applicatios that impacts in the awmaker project.

Regards,
kix
--
Rodolfo García Peñas (kix)
http://www.kix.es/

"I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

> Forget about moving wmaker out ofrepo.or.cz. This is not going to happen.

>
> I have the opinion that patches should be sent to the mailing list.
>
> Reading patches in the browser is not productive, sending comments in
> the browser is not productive. I strongly oppose this for wmaker.
>

> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/wmaker-dev/20200528085923.GB14426%40linux-lgsl.

[Roman Dobosz]

On Thu, 28 May 2020 09:59:23 +0100

"Carlos R. Mafra" <crm...@gmail.com> wrote:

> > What do people think?
>
> Forget about moving wmaker out of repo.or.cz. This is not going to happen.

I'm really disappointed by this decision, but… well. Given, that
wayland is managing pretty well release by release, seems like in
couple of years no one would give a damn about this project anymore :)

> I have the opinion that patches should be sent to the mailing list.
>
> Reading patches in the browser is not productive, sending comments in
> the browser is not productive. I strongly oppose this for wmaker.

Actually… reading patches and commenting in browser is not
productive… FOR YOU, while I bet, there are far more people (like
me), who feels the opposite.

--
-^- _ enjoying the silence
_ /O)_\//
(_(|__(_(_) grf.

[Carlos R. Mafra]

On Thu, 28 May 2020 at 16:13:33 +0200, Roman Dobosz wrote:
> On Thu, 28 May 2020 09:59:23 +0100
> "Carlos R. Mafra" <crm...@gmail.com> wrote:
>
> > > What do people think?
> >
> > Forget about moving wmaker out of repo.or.cz. This is not going to happen.
>
> I'm really disappointed by this decision, but… well. Given, that
> wayland is managing pretty well release by release, seems like in
> couple of years no one would give a damn about this project anymore :)

This is a logical fallacy: "slippery slope" [1]

There are thousands of other projects in repo.or.cz that do not
agree with you that they will become obsolete.

I understand why people like github because of all the bells and whistles,
I get that.

But stating that when wayland comes people will abandon wmaker because
it's not on github is not accurate nor fair.

I actually have a wmaker repository on github that I forget to update.
It was supposed to be a mirror of the repository in repo.or.cz:

https://github.com/crmafra/wmaker

I actually tried to update it last week, but somehow there was an issue
with the password and I gave up.

If it would make you happier and write patches for Wayland I can
figure out and update it as a mirror of repo.or.cz.

> > I have the opinion that patches should be sent to the mailing list.
> >
> > Reading patches in the browser is not productive, sending comments in
> > the browser is not productive. I strongly oppose this for wmaker.
>
> Actually… reading patches and commenting in browser is not
> productive… FOR YOU, while I bet, there are far more people (like
> me), who feels the opposite.

I understand that.

But I don't try to force my productivity tools on other people.

Look, my tone may be rough and it's not my intention to be rude.

But it's easy to say that the project is not "democratic" because
its maintainer didn't choose 12 years ago the tools others think he
should be using now.


[1] https://en.wikipedia.org/wiki/Slippery_slope

[Roman Dobosz]

On Thu, 28 May 2020 15:49:58 +0100

"Carlos R. Mafra" <crm...@gmail.com> wrote:

> On Thu, 28 May 2020 at 16:13:33 +0200, Roman Dobosz wrote:
> > On Thu, 28 May 2020 09:59:23 +0100
> > "Carlos R. Mafra" <crm...@gmail.com> wrote:
> >
> > > > What do people think?
> > >
> > > Forget about moving wmaker out of repo.or.cz. This is not going to happen.
> >
> > I'm really disappointed by this decision, but… well. Given, that
> > wayland is managing pretty well release by release, seems like in
> > couple of years no one would give a damn about this project anymore :)
>
> This is a logical fallacy: "slippery slope" [1]
>
> There are thousands of other projects in repo.or.cz that do not
> agree with you that they will become obsolete.

Ya, but I'm not talking about this particular hosting for repos nor
projects which it holds.

> I understand why people like github because of all the bells and whistles,
> I get that.

Actually, it is all about those bells and whistles. One can choose
whatever repository hosting service, just to have it publicly (or
not) available copy of the repo, just to get it available for backup
purposes, or an ease of share with others.

Although for projects, where several people are working on single
project, which also (oh no!) have users, which obviously are not
developers, ability for shorten the path to reach the project people
is a vital point. Time is passing, world moves on, new things
emerging. Preferences of the users/devs are shifting toward new
tools/ways of doing development. I guess, there is not so many
projects created on sourceforge comparing to github/gitlab. Just
saying.

> But stating that when wayland comes people will abandon wmaker because
> it's not on github is not accurate nor fair.

Oh no, this suppose to be a raw, plain rant :). Sorry about that. But
truth is, support for wayland is progressing. I'm not very keen of
change, but I already tried it out with tailing composer (sway) and
I must say, it's tempting for moving into i3 world… after some of the
rough edges will be fixed :)

OTOH, wayland progress has nothing to do with absence of wmaker on
github. My point was, that wmaker community is so small and hermetic,
that there is almost zero chance for arousing new users.

> I actually have a wmaker repository on github that I forget to update.
> It was supposed to be a mirror of the repository in repo.or.cz:
>
> https://github.com/crmafra/wmaker
>
> I actually tried to update it last week, but somehow there was an issue
> with the password and I gave up.
>
> If it would make you happier and write patches for Wayland I can
> figure out and update it as a mirror of repo.or.cz.

Personally, I do have my own mirror for wmaker source code:
https://github.com/gryf/wmaker, which is used as a backup right now,
so I don't mind.

Perhaps I should stress it more - I don't have issues with sending
patches to ML, but I do see benefits, which wmaker presence on github
could bring.

> > > I have the opinion that patches should be sent to the mailing list.
> > >
> > > Reading patches in the browser is not productive, sending comments in
> > > the browser is not productive. I strongly oppose this for wmaker.
> >
> > Actually… reading patches and commenting in browser is not
> > productive… FOR YOU, while I bet, there are far more people (like
> > me), who feels the opposite.
>
> I understand that.
>
> But I don't try to force my productivity tools on other people.

By not moving forward, well, you do in some extent :)

> Look, my tone may be rough and it's not my intention to be rude.
>
> But it's easy to say that the project is not "democratic" because
> its maintainer didn't choose 12 years ago the tools others think he
> should be using now.

It was just an idea to discuss. I hope, I presented clearly my point
of view for the subject. Perhaps, there are other people, who have
different opinion. Rodolfo was one of them, and, originally I was
referring to that discussion, he mentioned on his reply.

Cheers!

--
-^- _ something is grinding the emptiness:

_ /O)_\// Noise Unit - Miracle
(_(|__(_(_) grf.

[Carlos R. Mafra]

On Thu, 28 May 2020 at 20:54:23 +0200, Roman Dobosz wrote:
> It was just an idea to discuss. I hope, I presented clearly my point
> of view for the subject.

Yeah sure.

I don't think it would make a difference to attract users. Someone using
KDE will probably not suddenly change to wmaker because wmaker moved
to github and has a bug tracker, right?

******************************************************************
******************************************************************

I have a vision for wmaker which is more or less only bug fixes.

Some new features are welcome from enthusiastic people if they are
nice additions (like new maximizations, positioning of windows, keyboard
shortcuts etc).

I happen to be conservative on this front. I like my desktop to look and
behave exactly as it did 21 years ago when I started using wmaker. So far
that's been the case.

An approximate goal is wmaker to become like Donald Knuth's TeX.
It does the job and that's it (90% of my papers are written using
Knuth's plain TeX, that's the kind of person I am).

I use wmaker since 1999, and some time around 2008 the source
code repository was lost. After I got it from its creator I
established the -crm "fork".

It was meant to be a stable repository where people would send bug
fixes so that I could continue to use it. I think around 2008
my motivation was related to working with 64 bits in my new laptop.

After some time the -crm fork became the official repository. I welcomed
the new people, the new developers and there is a small group of
people who I blindly trust with new patches.

But at the same time, I am still the same. I just want to continue
to use the same wmaker for decades to come.

When you mention Wayland that makes me worry if maybe in 2030 I will be
forced to use something else because the cool guys dropped Xorg or
something.

So I worry about potential losses of developers because my life could
become more complicated if I have to write too many patches in 2030.

However, I don't believe that a wmaker user with the knowledge
will choose to not send patches adapting wmaker to Wayland or whatever
because he cannot click a button in github and doesn't want to
send patches to a mailing list.

I hope I am right, we'll see :)

[Roman Dobosz]

On Thu, 28 May 2020 20:47:51 +0100
"Carlos R. Mafra" <crm...@gmail.com> wrote:

> > It was just an idea to discuss. I hope, I presented clearly my point
> > of view for the subject.
>
> Yeah sure.
>
> I don't think it would make a difference to attract users. Someone using
> KDE will probably not suddenly change to wmaker because wmaker moved
> to github and has a bug tracker, right?

I guess no, although it might attract users from other minimalistic
window managers, who want to migrate to non-dead project.

[snip]

> However, I don't believe that a wmaker user with the knowledge
> will choose to not send patches adapting wmaker to Wayland or whatever
> because he cannot click a button in github and doesn't want to
> send patches to a mailing list.

I got your point. OTOH, I'm on IRC #windomaker channel, on which
sometimes people pops up, who have some issues or specific questions
regarding wmaker which I cannot answer, yet AFAIK none of them have
reach this very mailing list. That leads my twisted mind
for conclusion, maybe it would be beneficial for having another
source of users feedback, which finally leads to this crazy idea for
unifying whole repos related to wmaker under one place.

--
-^- _ something is grinding the emptiness:

_ /O)_\// Front Line Assembly - Machine Slave
(_(|__(_(_) grf.

[Kostas Michalopoulos]

FWIW i think that having a bug tracker is a good idea since it can
help with keeping, well, track of bugs :-P (e.g. i was curious about
the icons bug i fixed some time ago if it was a known thing), but it
doesn't need to be GitHub.

There are a lot of bug tracking applications out there and one can
simply be put on windowmaker.org. Some other projects i've worked with
use Mantis BT which is very lightweight and has very few system and
software requirements (essentially PHP and some database) that should
exist in any web server.

Kostas

> --
> You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/wmaker-dev/20200529173443.e639f2e140622799e093d365%40gmail.com.

[Doug Torrance]

On Sat, May 30, 2020 at 3:48 AM Kostas Michalopoulos
<badsect...@gmail.com> wrote:
> FWIW i think that having a bug tracker is a good idea since it can
> help with keeping, well, track of bugs :-P (e.g. i was curious about
> the icons bug i fixed some time ago if it was a known thing), but it
> doesn't need to be GitHub.

I agree that a bug tracker would be very helpful! Apparently, we used
to have one, as bugs.windowmaker.org is still mentioned in the FAQ!

> There are a lot of bug tracking applications out there and one can
> simply be put on windowmaker.org. Some other projects i've worked with
> use Mantis BT which is very lightweight and has very few system and
> software requirements (essentially PHP and some database) that should
> exist in any web server.

The website is static, generated by Jekyll and hosted by Github Pages.
So at least in its current state, we don't have the ability to run a
dynamic web app like a bug tracker ourselves. And if I recall, the
move to Github Pages (and to Google Groups for this list) was
motivated by a desire not to deal with that kind of overhead.

Assuming that we don't want to get back in the game of hosting
something ourselves again, it would be nice to find some sort of free
hosted bug tracker. I can't really find anything other than Github.
Is there anything else out there?

One option would be to use Github strictly for issues. We could have
a clone of the main repository there, with a prominent note to use the
mailing list instead of pull requests in the description, and only use
its issues page. Or just have post issues in "wmaker-bugs" repository
that's just a README file.

Doug

[Carlos R. Mafra]

On Sat, 30 May 2020 at 8:25:03 -0400, Doug Torrance wrote:
>
> One option would be to use Github strictly for issues. We could have
> a clone of the main repository there, with a prominent note to use the
> mailing list instead of pull requests in the description, and only use
> its issues page. Or just have post issues in "wmaker-bugs" repository
> that's just a README file.

That could work, but it seems a bit odd even for me :)

If all people want is the repository on github for the bug tracker,
then why not? Here:

https://github.com/crmafra/wmaker

is the lastest master branch and I pledge to keep it updated when
I update the repo.or.cz repository.

Would that work?

[Doug Torrance]

We could potentially also have it under the existing Window Maker
organization, where the websites live:
https://github.com/window-maker

[Rodolfo García Peñas]

> --
> You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/wmaker-dev/CALrgpkqaNYYXJeVSUZbRPKG0r3DtM_cnr2pXsMqCO6Zud7%2BCNQ%40mail.gmail.com.
>

+1 for the window-maker organization
+1 to move the repo to github

my votes are still valid, no?

kix@inle:~/tmp/wmaker-crm$ git log | grep ^Autho | sort | uniq -c |sort
-n | tail -10
77 Author: Iain Patterson <w...@iain.cx>
84 Author: Doug Torrance <dtor...@piedmont.edu>
99 Author: David Maciejak <david.m...@gmail.com>
116 Author: Tamas TEVESZ <i...@extreme.hu>
182 Author: id <id>
256 Author: Carlos R. Mafra <crm...@gmail.com>
320 Author: Rodolfo García Peñas (kix) <k...@kix.es>
507 Author: kojima <kojima>
701 Author: Christophe CURIS <christop...@free.fr>
813 Author: dan <dan>
kix@inle:~/tmp/wmaker-crm$

[Carlos R. Mafra]

That's good for me, thanks.

[Rodolfo García Peñas]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

> ------------------------------

>
> You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/wmaker-dev/20200530153821.GA18492%40linux-lgsl.

Finally, can we move the repo to github, not only the bugs?

Votes to move to github:

- kix

Votes to hold in repo.or.cz:

-


How many days hold this votation open? One week? Ends the next 06/06/2020?

[Carlos R. Mafra]

On Sat, 30 May 2020 at 15:45:26 +0000, Rodolfo García Peñas wrote:
> Finally, can we move the repo to github, not only the bugs?

https://github.com/crmafra/wmaker

Happy?

Patches must be sent to the mailing list.

[Rodolfo García Peñas]

> --
> You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/wmaker-dev/20200530155805.GA18995%40linux-lgsl.
>

No,

must be in the window-maker organization

kix

[Carlos R. Mafra]

Rodolfo, I won't follow your orders.

[Rodolfo García Peñas]

I don't want it. I proposed move the project to the window-maker
organization. Doug is managing this organization, not me. I am not
member of that organization. Probably Doug can create a team,...

But should we follow yours?

crm> Forget about moving wmaker out of repo.or.cz. This is not going to
happen.

When the people follow your orders, all is nice. When someone propose to
move to github, or something that means you lost the control of the
project, then is bad. You will kill this project yourself.

I don't want nobody follow my orders. People here can take their own
decisions. But don't expect I follow yours.

[Doug Torrance]

Alrighty, it's up:
https://github.com/window-maker/wmaker

I also added a blurb to the bottom of the front page of windowmaker.org.

Doug

[Carlos R. Mafra]

Awesome. Thank you, Doug!

[HAROLDO GAMBINI SANTOS]

Hi Carlos,

My 2 cents:

Having a stable repository is good but it would be great also to motivate those who would like to contribute new features to WindowMaker. These features could be kept in "experimental" branches in git until you are more confident that they are stable enough to be incorporated in master. 

There are very few developers interested in WindowMaker today, it would be sad to have a small and fragmented community. Maybe among those developers that start contributing superfluous patches today there is someone that in the future could solve one of the important WindowMaker problems today, for example:

- eventual crashes: I use windowmaker in several computers, I'm sure that there are still many heisenbugs hidden in the code, as much as I love WM, I don't think that the comparison with Knuth Tex is appropriate :)

- smooth handle of new monitors without restart

- keyboard navigation in wings

...

+1 for the organization  BTW, if my "two patches in the whole life" qualify, I would like to be included in, my current github profile is here: https://github.com/h-g-s

+1 for move to github

Cheers,

Haroldo

--
You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wmaker-dev/20200528194751.GA9414%40linux-lgsl.

--

=============================================================
Haroldo Gambini Santos
Computing Department
Universidade Federal de Ouro Preto - UFOP
email: har...@ufop.edu.br
home/research page: www.decom.ufop.br/haroldo


It has long been an axiom of mine that the little things are infinitely
the most important.
-- Sir Arthur Conan Doyle, "A Case of Identity"

[Doug Torrance]

On Sat, May 30, 2020 at 8:01 PM HAROLDO GAMBINI SANTOS
<har...@ufop.edu.br> wrote:
> +1 for the organization BTW, if my "two patches in the whole life" qualify, I would like to be included in, my current github profile is here: https://github.com/h-g-s

I went ahead and sent an invite to (I think) everyone who's made a
contribution in the past year and has a Github account. Let me know
if you didn't get an invitation and would like to be included.

Right now, I don't think membership in the organization does anything
special other than let you say, "Hey, look -- I'm a member of Window
Maker's Github organization!" :)

Doug

[Carlos R. Mafra]

On Sat, 30 May 2020 at 21:01:17 -0300, HAROLDO GAMBINI SANTOS wrote:
>
> There are very few developers interested in WindowMaker today, it would
> be sad to have a small and fragmented community. Maybe among those
> developers that start contributing superfluous patches today there is
> someone that in the future could solve one of the important WindowMaker
> problems today, for
> example:
> - eventual crashes: I use windowmaker in several computers, I'm sure that
> there are still many heisenbugs hidden in the code, as much as I love WM, I
> don't think that the comparison with Knuth Tex is appropriate :)
> - smooth handle of new monitors without restart
> - keyboard navigation in wings
> ...

Of course, and if you see the git log you'll notice that whenever people
have patches for things they care enough to write patches in the first
place, I accept them if they look good and pass the "I don't think this
is crackpot material" test.

I believe that the people who hang around here know this, do scratch your
own itch and write patches for them. Absolutely.

I agree that we have issues.

1. the restart I can live with, but I wrote the code in the first
place and although it works for me I am not proud of it.
The fix will not be minimal and that's the motivation for
Rodolfo's fork I believe.

2. Keyboard navigation in wings, it would be nice to have.
Maybe this is not so complicated. Even though it touches
the library I would not mind trying it.

3. I have a way to generate a crash that is not even a heisenbug.
It happens everytime, but rarely and when I mess up something.

When I switch between my laptop screen and an
external monitor, disable the laptop screen, then if the monitor
screen goes out and I have to use the laptop again. The screen
is disabled and if I manage to type in the terminal to enable the
screen again (guessing because the screen is black) then wmaker
comes back up totally messed up after restarting.
The dock icons disappear and I
have to use a backup of my GNUstep/Defauts file, for which I have
to log out of X, log in to another text terminal, copy the file and
then log back in with X.

This of course angers me, but it rarely happens. Maybe once every
year or so.

4. It would be nice to have a user file from which wmgenmenu reads the list
of programs, not a list hard-coded into the program itself.

So yeah, if people write patches for wmaker and they are good and sane,
I'll take it for sure.

[Roman Dobosz]

Yay! It finally happen. Thanks!

Hint - although you cannot disable pull request tab, you can do that
with wiki and projects, since we don't plan to use them :)

[Roman Dobosz]

On Sun, 31 May 2020 07:50:59 +0100

"Carlos R. Mafra" <crm...@gmail.com> wrote:

Nice list! Perhaps it's worth to fill the issue on GH for every each
of them.

> I agree that we have issues.
>
> 1. the restart I can live with, but I wrote the code in the first
> place and although it works for me I am not proud of it.
> The fix will not be minimal and that's the motivation for
> Rodolfo's fork I believe.

I've already briefly read the code from couple of other window
managers, how they handle events with appearing/disappearing
monitors, although didn't deep dive into it yet.

> 2. Keyboard navigation in wings, it would be nice to have.
> Maybe this is not so complicated. Even though it touches
> the library I would not mind trying it.
>
> 3. I have a way to generate a crash that is not even a heisenbug.
> It happens everytime, but rarely and when I mess up something.
>
> When I switch between my laptop screen and an
> external monitor, disable the laptop screen, then if the monitor
> screen goes out and I have to use the laptop again. The screen
> is disabled and if I manage to type in the terminal to enable the
> screen again (guessing because the screen is black) then wmaker
> comes back up totally messed up after restarting.
> The dock icons disappear and I
> have to use a backup of my GNUstep/Defauts file, for which I have
> to log out of X, log in to another text terminal, copy the file and
> then log back in with X.
>
> This of course angers me, but it rarely happens. Maybe once every
> year or so.

I have similar experience with only one monitor. I have a headless
machine, which I'm occasionally run with X/wmaker. I've noticed, that
when it is not connected to any monitor, Xorg was not able to detect
it obviously, and it set screen resolution to 8 x 8 pixels, which
than causes total mess with dockapps in dock - to be precise most (or
all) of them are gone after restart. Probably cause for this behavior
is the fact, that dock cannot have docked items which are exceeding
screen resolution.

> 4. It would be nice to have a user file from which wmgenmenu reads the list
> of programs, not a list hard-coded into the program itself.

IMHO, that should be done dynamically. Although I don't care about
generated menu for application, I do see the need for the users.

Using ability of dynamic menus, I'd created a proof of concept[1],
which generate such menu. Maybe it's worth to think of creating it
with dedicated type of menu item to be put in main menu. Script is
simple - it looks into .dektop entries located
in /usr/share/applications, and grab name, executable and first
category. Than it make the submenu for every category and put the
item in it.

If one would like to check that PoC[1], all it needed to be done is
to download script, make it executable, optionally change the path
where *desktop files lies (line 9, default
is /usr/share/applications), create new entry in WPrefs' menu as
"Generated Submenu" and put the path to the script.

[1] https://gist.github.com/gryf/fa460d5e728d22cdf87c72fd9183bbc1

--
-^- _ something is grinding the emptiness:

_ /O)_\// Front Line Assembly - Terminal Power
(_(|__(_(_) grf. State of Mind

[Carlos R. Mafra]

On Sun, 31 May 2020 at 10:52:07 +0200, Roman Dobosz wrote:
>
> > 4. It would be nice to have a user file from which wmgenmenu reads the list
> > of programs, not a list hard-coded into the program itself.
>
> IMHO, that should be done dynamically. Although I don't care about
> generated menu for application, I do see the need for the users.
>
> Using ability of dynamic menus, I'd created a proof of concept[1],
> which generate such menu. Maybe it's worth to think of creating it
> with dedicated type of menu item to be put in main menu. Script is
> simple - it looks into .dektop entries located
> in /usr/share/applications, and grab name, executable and first
> category. Than it make the submenu for every category and put the
> item in it.
>
> If one would like to check that PoC[1], all it needed to be done is
> to download script, make it executable, optionally change the path
> where *desktop files lies (line 9, default
> is /usr/share/applications), create new entry in WPrefs' menu as
> "Generated Submenu" and put the path to the script.
>
> [1] https://gist.github.com/gryf/fa460d5e728d22cdf87c72fd9183bbc1

Did you look at wmmenugen in the /utils folder? It was written
by Tamas TEVESZ and if I recall correctly already does what you
describe.

The other program, wmgenmenu was written by me inspired by
a shell script wmgenmenu.sh written by someone else which I found
by chance and had a hard-coded list of programs to look for.

Obviously this was meant to be a hack for personal use and I don't
mind having it hard-coded. But someone might add the option to read
the list from a file in the user directory, maybe .wmgenmenurc.

[Rodolfo García Peñas]

Hi Roman,

for your info.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Sunday, 31 de May de 2020 10:52, Roman Dobosz <gry...@gmail.com> wrote:

> On Sun, 31 May 2020 07:50:59 +0100
> "Carlos R. Mafra" crm...@gmail.com wrote:
>
> Nice list! Perhaps it's worth to fill the issue on GH for every each
> of them.
>
> > I agree that we have issues.
> >
> > 1. the restart I can live with, but I wrote the code in the first
> > place and although it works for me I am not proud of it.
> > The fix will not be minimal and that's the motivation for
> > Rodolfo's fork I believe.
> >
>
> I've already briefly read the code from couple of other window
> managers, how they handle events with appearing/disappearing
> monitors, although didn't deep dive into it yet.

windowmaker was created from the scratch, using X11.

windowmaker do not uses objects, structs or something to create the elements and then draw them on the screen. wmaker just call X11 functions to create these elements.
It include dockapps, windows, menus,...

In Qt, Gtk,... elements are created as objects/structs. Then you can call a function to draw them on the screen. Are different steps. So you can create a menu, draw in the screen, select the element, destroy the menu in the X11, destroy the menu object. There is an abstraction between the element and the screen (X11, win32, wayland,...)

In wmaker, some elements are created when wmaker starts. For example, root menu, window menu:

https://github.com/window-maker/wmaker/blob/master/src/startup.c#L582

The menu is created in X11 (yes, text, lines, background,...), and then hidden. That is nice for many things. For example, with a new window, you can add it to the (hidden) menu. When the user make click on the background wmaker just unhide the menu. For example, the window-list-menu is the same in the root-menu and the window-list-menu itself (it is just moved, both are already created)

But, this behavior adds communication between wmaker and X11 when the user open a new window, close the window, move the window between workspaces,... And the menu must be re-painted (yes, re-painted, but it is probably hidden). Sometimes, create the elements, when are not used, is not good. For example to restore and hide the root menu, it is painted at x = -10000 y = -10000:


https://github.com/window-maker/wmaker/blob/master/src/screen.c#L873

void wScreenRestoreState(WScreen * scr)
{
WMPropList *state;
char *path;

OpenRootMenu(scr, -10000, -10000, False);
wMenuUnmap(scr->root_menu);


What's happens when the user adds a new monitor? Yes, elements are in the screen and the only way in wmaker is restart it.

In awmaker I am trying to solve these things. For example, menus are created only when the user call the menu. When a new window is created, the callback for a new menu entry is called, but if the menu is not created, the callback just do nothing. Less CPU, less X11 communication. With this idea, in the future, when the user adds a new screen, wmaker can remove the menu, and then draw it again (without restart).

awmaker is not fully stable (I don't have crashes, but some things are not fine painted). IMHO awmaker is faster, it has less interaction with X11 (less calls). awmaker is not the window manager for users, now. In the future, when things will be fine, the idea is merge the code with wmaker. I am including all wmaker patches in awmaker, so we have the same functionality. Perhaps some things of awmaker could be translated to wmaker.

Making changes is not easy. I am trying to hold fully compatibility with wmaker and I need add some intermediate states. But many things are better. For example, I don't need brother's menu in awmaker:

https://github.com/window-maker/wmaker/blob/master/src/menu.h#L53
https://github.com/awmaker/awmaker/blob/master/src/menu.h#L52

Currently, I am working with the icons position (coords).

One of the problems are the positions. wmaker uses a fixed positions of the elements, related to the x=0, y=0. If the new monitor has different resolution, then the icons are in the middle of the screen, or outside of the screen. And is not possible to move them inside the screen.

My idea about that is create relative positions with up-right, up-left, down-right and down-left. When the element is painted, the position is not fixed, it is calculated (and saved) for the new device/devices.

>
> > 4. It would be nice to have a user file from which wmgenmenu reads the list
> > of programs, not a list hard-coded into the program itself.
> >
>
> IMHO, that should be done dynamically. Although I don't care about
> generated menu for application, I do see the need for the users.
>
> Using ability of dynamic menus, I'd created a proof of concept[1],
> which generate such menu. Maybe it's worth to think of creating it
> with dedicated type of menu item to be put in main menu. Script is
> simple - it looks into .dektop entries located
> in /usr/share/applications, and grab name, executable and first
> category. Than it make the submenu for every category and put the
> item in it.
>
> If one would like to check that PoC[1], all it needed to be done is
> to download script, make it executable, optionally change the path
> where *desktop files lies (line 9, default
> is /usr/share/applications), create new entry in WPrefs' menu as
> "Generated Submenu" and put the path to the script.
>
> [1] https://gist.github.com/gryf/fa460d5e728d22cdf87c72fd9183bbc1

IMHO all should be dynamic and self-contained in wmaker. Menus should be created dynamically, but also configuration files. wmaker.inst should be "included" inside the wmaker code.

> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>
> -^- _ something is grinding the emptiness:
>
>

> _ /O)\// Front Line Assembly - Terminal Power
> ((|__(() grf. State of Mind
> -------------------------------------------------------------------------

>
> You received this message because you are subscribed to the Google Groups "Window Maker Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wmaker-dev+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/wmaker-dev/20200531105207.781ccf8e1b33eb722610784d%40gmail.com.

[Roman Dobosz]

On Sun, 31 May 2020 10:40:40 +0100

"Carlos R. Mafra" <crm...@gmail.com> wrote:

> > Using ability of dynamic menus, I'd created a proof of concept[1],
> > which generate such menu. Maybe it's worth to think of creating it
> > with dedicated type of menu item to be put in main menu. Script is
> > simple - it looks into .dektop entries located
> > in /usr/share/applications, and grab name, executable and first
> > category. Than it make the submenu for every category and put the
> > item in it.
> >
> > If one would like to check that PoC[1], all it needed to be done is
> > to download script, make it executable, optionally change the path
> > where *desktop files lies (line 9, default
> > is /usr/share/applications), create new entry in WPrefs' menu as
> > "Generated Submenu" and put the path to the script.
> >
> > [1] https://gist.github.com/gryf/fa460d5e728d22cdf87c72fd9183bbc1
>
> Did you look at wmmenugen in the /utils folder? It was written
> by Tamas TEVESZ and if I recall correctly already does what you
> describe.

No, I didn't. And yes, it can generate similar menu.

> The other program, wmgenmenu was written by me inspired by
> a shell script wmgenmenu.sh written by someone else which I found
> by chance and had a hard-coded list of programs to look for.
>
> Obviously this was meant to be a hack for personal use and I don't
> mind having it hard-coded. But someone might add the option to read
> the list from a file in the user directory, maybe .wmgenmenurc.

Yeah. wmgenmenu generates whole menu, which include apps, but also
wmaker specific items (like Run, appearance menu, workspaces, info,
exit and so on). Maybe an option would be to instead creating
hardcoded app menu within, just make dynamic one, like:

(Applications, OPEN_PLMENU, "|| wmmenugen -parser xdg /usr/share/applications")

So after the first run, user should see all installed application in
his system. And after he add or remove some of them, menu will
follow. What do you think?

--
-^- _ something is grinding the emptiness:

_ /O)_\// Front Line Assembly - Consequence

[Roman Dobosz]

On Sun, 31 May 2020 10:07:44 +0000
Rodolfo García Peñas <k...@kix.es> wrote:

> Hi Roman,
>
> for your info.

[..]

Nice! Thanks for the explanation!

--
-^- _ something is grinding the emptiness:

_ /O)_\// Front Line Assembly - And They Shall Bow

[Carlos R. Mafra]

For my personal use I don't want my menu to be polluted by every
single application in the system. I just want the menu to have the
applications I frequently use and care about.

That's why I used the script wmgenmenu.sh and at some point wrote
a C version that was later included in wmaker.

But we now have other options, like the one you suggest. Most people
will probably like that better.

People can do what they want, and that is good.

I just mentioned wmgenmenu because I think it could be improved, tweaked.
Maybe I will do that at some point, since I clearly care about it :)

[Roman Dobosz]

On Sun, 31 May 2020 12:20:18 +0100
"Carlos R. Mafra" <crm...@gmail.com> wrote:

> > > Did you look at wmmenugen in the /utils folder? It was written
> > > by Tamas TEVESZ and if I recall correctly already does what you
> > > describe.
> >
> > No, I didn't. And yes, it can generate similar menu.
> >
> > > The other program, wmgenmenu was written by me inspired by
> > > a shell script wmgenmenu.sh written by someone else which I found
> > > by chance and had a hard-coded list of programs to look for.
> > >
> > > Obviously this was meant to be a hack for personal use and I don't
> > > mind having it hard-coded. But someone might add the option to read
> > > the list from a file in the user directory, maybe .wmgenmenurc.
> >
> > Yeah. wmgenmenu generates whole menu, which include apps, but also
> > wmaker specific items (like Run, appearance menu, workspaces, info,
> > exit and so on). Maybe an option would be to instead creating
> > hardcoded app menu within, just make dynamic one, like:
> >
> > (Applications, OPEN_PLMENU, "|| wmmenugen -parser xdg /usr/share/applications")
> >
> > So after the first run, user should see all installed application in
> > his system. And after he add or remove some of them, menu will
> > follow. What do you think?
>
> For my personal use I don't want my menu to be polluted by every
> single application in the system. I just want the menu to have the
> applications I frequently use and care about.

I totally understand your point, because I do have my own menu, which
for sure will be totally odd for someone else. Even though, I'm using
dynamic menus for several things (for example vbox VMs), I rarely add
new items for apps.

> That's why I used the script wmgenmenu.sh and at some point wrote
> a C version that was later included in wmaker.

While that's a great starting point for new users, I didn't use that
for years. My typical new installation is to copy GNUstep directory
to new installation and that's it :)

> But we now have other options, like the one you suggest. Most people
> will probably like that better.
>
> People can do what they want, and that is good.

Yup!

> I just mentioned wmgenmenu because I think it could be improved, tweaked.
> Maybe I will do that at some point, since I clearly care about it :)

Nice!

[Doug Torrance]

Done!