fvwm history web page needs update?
hi, looking at this page: http://fvwm.org/history.php i think it needs updating to reflect newer fvwm - who needs to add additional information here? Thanks! Michael
Re: Monitor improvements on master
hi, can i use this from the perl bindings? i didnt see a way to do this. Michael On 25 December 2014 at 00:14, Thomas Adam tho...@fvwm.org wrote: Hi all, As with myself, I know many of you will be busy over this time. I have, for a while now, had a topic branch brewing for some time (ta/various-monitor-improvements) which has laid the groundwork for internal API changes to how monitor information is sent to modules. To do this, I've augmented the CONFIGARGS macro to include a monitor id. This ID is a number which is assigned to each module struct when it is created based on poking RandR for this information. Then, modules wishing to use monitor-specific information can get a struct monitor pointer looking up the monitor based on the id. This means there doesn't have to be any clever trickery trying to maintain a struct monitor pointer sent to modules, which wouldn't work too well anyway. Hopefully in the future this will become much more opaque via the use of, say, libevent. I wanted to do this so that I can fix the pager to be monitor aware. As it happens, that's not quite finished yet; instead, only Ident is making use of this to now include the name of the monitor the selected window is on. By all means test this out, and let me know if there's any oddities. I've ben using this code for many months without any ill-effects, but my own limited testing might not be enough, so feedback welcome. Any questions, do please ask. -- Thomas Adam
mvwm - typedef removes?
hi, Again in this TODO file there are these points - - Don't use typedefs for structs: - Opaqueness is not useful here! - 'struct foo' versus 'foo_t' or 'Foo' as the type. - Will allow for reducing the number of structs used as the main API, and will allow for better streamlining and accessing. - There's a lot of macro #defines for accessing struct members, presumably to hide the type; that's usually OK, but I'd like to see these go away. FW and Decor are good examples of this! I'd rather see more exposed functions to replace these. The API will need discussion. what does this mean? i like macros for accessing things in a struct so that if the item in the struct changes then nothing gets to change. Michael
Re: mvwm - tailq?? (on ta/various-monitor-fixes)
On 28 October 2014 11:21, Thomas Adam tho...@fvwm.org wrote: On Tue, Oct 28, 2014 at 10:26:20AM +, Michael Treibton wrote: hi, looking at the code on ta/various-monitor-fixes i see theres something called TAILQ - is this a list implementation? why is it used? can you not use your own lists? why are the monitors using it? Because I added it. One of the biggest bugbears I have are many list implementations which necessitate writing a fair amount of boilerplate code. The TAILQ implementation is useful because it abstracts all of that and leaves you with just a few macros to add/remove items, as well as search for things, etc. but mvwm already uses lists which are hand created and now this monitor lists look odd. Michael
Re: Fvwm project
On 20 October 2014 10:19, Michael Treibton mtreib...@googlemail.com wrote: On 15 October 2014 20:15, Michael Treibton mtreib...@googlemail.com wrote: On 13 October 2014 22:53, Dan Espen des...@verizon.net wrote: I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? I've often wondered - but also i dont care what format my files are in as long as they just work. that said, i dont like this change much either because its too disuptive to other people. can we not do this? so can we get an official answer? i know Thomas is active because i see code changes - so is this a fork proper or not? i suppose we all have our answer. Thanks for the conversation, i look forward to the time when mvwm merges with fvwm but even converting my config over is a lot of effort now. annoyed, Michael
Re: Fvwm project
On 15 October 2014 20:15, Michael Treibton mtreib...@googlemail.com wrote: On 13 October 2014 22:53, Dan Espen des...@verizon.net wrote: I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? I've often wondered - but also i dont care what format my files are in as long as they just work. that said, i dont like this change much either because its too disuptive to other people. can we not do this? so can we get an official answer? i know Thomas is active because i see code changes - so is this a fork proper or not? Michael
Re: Fvwm project
On 13 October 2014 22:53, Dan Espen des...@verizon.net wrote: I don't see the sense in removing xpm, svg, bmp, etc. support. How many lines of code does that save? I've often wondered - but also i dont care what format my files are in as long as they just work. that said, i dont like this change much either because its too disuptive to other people. can we not do this? I can imagine it saves some amount of non-resident memory, but if you don't have xpms, libxpm should not be using any significant real memory. Otherwise, it just causes issues for users. agree. But my real issue is moving the development source to another location and not documenting anything about it. That, and changing the name of fvwm to something else. If you want to fork, say so. i dont know how official it is but i consider mvwm a fork - and why not? what difference is it making either way? i know that if i want to use mvwm i have to update my config - and that's ok - is it not? Michael
Re: mvwm - things I'd like to see
On 3 September 2014 23:18, Dominik Vogt dominik.v...@gmx.de wrote: Well, if you run into problems you can always ask for help un the users' mailing list. is it still developed? Not by me, and I do not know if anybody maintains it. The last change was by thomas: https://github.com/ThomasAdam/fvwm-themes/commit/49f4091e743d0a639223abf44016785996fc4548 that was 4 years ago. Granted. I don't like the pixmap implementation either; it was part of a compromise because many people kept nagging about rounded window edges and things like that. the TODO file in mvwm suggests this might get reworked? Neither do I. But we can hardly add every odd scripting language to the window manager just because someone likes it. I can remember the fvwm-spinoff called scwm (scheme configurable window manager) which was (afaik) given up because scheme configuration turned out to be too slow. yes, Thomas mentioned this in another thread - it looked interesting but ultimately slow. The decision about the scripting implementation in the new core is still open, but we need facts and thinking about the correct choice of the language. i see these things in the TODO file: - The module interface (FVWM - Module) is a mess; consider DBUS? Or imsg? - Use libevent to replace the hand-rolled (and often broken) select/poll mechanism. - What about third-party scripting languages? How do we handle that without requiring linking against the specific language in question? i don't know if all three are related to scripting core, but what does the last item mean? is that relating to a choice of language? thank you for your time. Michael
mvwm - things I'd like to see
Hi, Here's some of the things I'd like: - no more motif borders (horrible) - fluxbox style window borders - xdg menus by default - diff. border colors for each side - lua scripting interface i think lua is important because it lets people extend mvwm in ways not possible right now. I've also seen weirdness with mvwm and xrandr - the multiple monitor feature just about hangs in there with functionality but i think it needs fixing. Michael
Re: mvwm - things I'd like to see
On 3 September 2014 22:27, Dominik Vogt dominik.v...@gmx.de wrote: On Wed, Sep 03, 2014 at 10:01:37PM +0100, Michael Treibton wrote: Here's some of the things I'd like: - no more motif borders (horrible) With fvwm you can more or less configure every border style you want. Have you tried the themes package? Theming could be better integrated into the distribution, though. fvwm-themes? Seems old and didn't work well for me last time. is it still developed? - fluxbox style window borders Borders in fluxbox are also very configurable. Do you have a screenshot of what you mean? Here is one: http://files.samhart.net/img/misc/flux-tab-example.png - look at the bottom border. - diff. border colors for each side Can already be done with pixmap borders. but why must i make pixmaps for each color that i want? i have colorsets for this, don't i? Could you please elaborate on what you think fvwm is missing in terms of scripting flexibility? (Other than fvwm's scripting language can be awkward - we're working on that.) That, and i don't like perl? Everything is using dedicating embedded things like lua from the outset, so why can't this wm? Note that mvwm is not going to be a brand new window manager that does everything from scratch. It will be a very much improved fvwm with maybe a few antique things removed. Regarding window handling and window decorations it won't change much for now. i think i understand that, yes. But i don't always see if this approach is good or not - why not write it from scratch? wasn't that the original intent? Michael
Re: FVWM: next stable release? (dont shoot!)
On 13 June 2010 21:54, Thomas Adam tho...@xteddy.org wrote: If you don't see a commit from me by Wednesday, shout at me and I'll do something about it. But please do remind me. did you manage this? M. Treibton
