kyak changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
jwhitmore has joined #qi-hardware
jwhitmore has quit [Ping timeout: 244 seconds]
sandeepkr has quit [Ping timeout: 244 seconds]
sb0 has joined #qi-hardware
sb0 has quit [Ping timeout: 246 seconds]
sb0 has joined #qi-hardware
MistahDarcy has joined #qi-hardware
MistahDarcy has quit [Ping timeout: 260 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
<whitequark> DocScrutinizer51: I just committed DXF import to SolveSpace
doomlord_ has joined #qi-hardware
arossdotme has quit [Ping timeout: 260 seconds]
<wpwrak> whitequark: btw, when you have "connected" geometries, how do you transport bits from one to the other ? e.g., in the case of the anelok case, the "wedge" is made of two circles and both outer tangents. i don't know the length of the tangents (without calculating it). that length would in turn go to anything that defines the top side. e.g., a window or window frame. how would solvespace transport that value (or equivalent) from one ske
<wpwrak> tch to the next ?
<whitequark> I have no idea what are you talking about
<wpwrak> ;-)
<whitequark> "wedge"? wtf
<wpwrak> thought you knew it
<wpwrak> on the side, the battery defines one circle. there's another one on the other end, smaller (with a more or less arbitrary radius)
<wpwrak> i have the two radii plus the distance between the two centers
<wpwrak> the top and bottom flat side is basically the two outer tangents on these circles / cylinders, extruded down the width of the case
<wpwrak> now, one would want to do things that are based on the geometry of these flat sides. such as placing a window at the right spot
<wpwrak> now would the 2D sketch that defines what's going on on the flat sides learn the length of the tangent ?
<wpwrak> (or the points / lines where tangents touch circle / cylinder)
<whitequark> solvespace does not have 2d sketches
<whitequark> all sketches are inherently 3d, although when you are drawing "in 2d", all points are implicitly constrained in plane
<wpwrak> so you do it all in the same 3D space as the main model ?
<whitequark> there's no "main model"
<whitequark> every sketch has one global coordinate space
<wpwrak> so it's all in the same 3D space
<whitequark> yep
<wpwrak> okay, that should make this sort of "export/import" trivial
<wpwrak> also probably also more understandable than the mix of "sketches" and other stuff in freecad :) (i dodge all this by scripting model generation, but that's of course not really the nicest way)
sb0 has quit [Quit: Leaving]
kilae has joined #qi-hardware
sb0 has joined #qi-hardware
sandeepkr has joined #qi-hardware
jwhitmore has joined #qi-hardware
<wpwrak> whitequark: playing with solvespace ... how do you use variables for geometry constraints
<wpwrak> err, i mean for dimensions
<wpwrak> and when it goes red, it seems there's not much of a choice but to backpedal out with undo ? or is there a way to find out what's wrong and fix it more directly
<wpwrak> ?
pcercuei has joined #qi-hardware
<wpwrak> same point constraints seem to come apart when it goes red :(
<wpwrak> also not so nice that redundant constraints make it go red, without indicating where the conflict is
<wpwrak> nice that one can select constraints directly. not so nice: if two share the same indication, one sees only one
<wpwrak> whitequark: the number of arc segments is sometimes confusingly low
<wpwrak> whitequark: playing with my wedge shape: http://downloads.qi-hardware.com/people/werner/slvs/wedge-070654.slvs
<wpwrak> not everything is quite right there, though. e.g., there should be a global "wall thickness" parameter that gets used to calculate the big cylinder-arc (or whatever this is called) based on its inner cylinder, which is in turn battery diameter + a bit of slack
wildlander has joined #qi-hardware
<wpwrak> the browser window is a bit inconvenient: should either stay on top of the main window or at least the main window shouldn't raise itself when clicked
pcercuei has quit [Quit: leaving]
<DocScrutinizer05> not like there are no desktops that can do that
sandeepkr_ has joined #qi-hardware
sandeepkr_ has quit [Max SendQ exceeded]
sandeepkr has quit [Ping timeout: 260 seconds]
sandeepkr_ has joined #qi-hardware
sandeepkr__ has joined #qi-hardware
sandeepkr_ has quit [Ping timeout: 252 seconds]
xiangfu has joined #qi-hardware
pcercuei has joined #qi-hardware
sb0 has quit [Quit: Leaving]
sb0 has joined #qi-hardware
wej has quit [*.net *.split]
pcercuei has quit [Quit: leaving]
xiangfu has quit [Remote host closed the connection]
arossdotme has joined #qi-hardware
arossdotme-planb has joined #qi-hardware
<whitequark> wpwrak: you can't use variables in constraints (yet)
<whitequark> wpwrak: when it goes red, the browser window shows which constraints are problematic and what you can do about it
<wpwrak> ewww :(
<wpwrak> ah, should position the browser window more prominently then. i only found it by accident
<whitequark> 'position'?
<whitequark> the browser window is extremely important in solvespace, everything is done through it
<wpwrak> it disappears easily under the model window
<whitequark> your WM is broken
<whitequark> there's an "always on top" flag set on the browser window
<wpwrak> that information doesn't seem t make it
<wpwrak> (using fvwm here)
<whitequark> it's the standard icccm flag. i3 respects it
<whitequark> ditto any common WMs (kwm and whatever gnome and unity use)
<DocScrutinizer05> whitequark: wpwrak's window manager is known to not support those flags like "always on top"
<whitequark> DocScrutinizer05: "< whitequark> your WM is broken"
<DocScrutinizer05> that's why I answered
<whitequark> i specifically positioned it more prominently
<whitequark> dunno what else can i do
<whitequark> wpwrak: "the number of arc segments is sometimes confusingly low" configuration -> chord tolerance
<whitequark> for display it's specified in % of model bounding box
<whitequark> since that gives you consistent results regardless of part scale
<whitequark> for export it's specified in mm, e.g. if you want to 3d-print
<DocScrutinizer05> how about (heresy warning) a non-multiwindowed UI?
<whitequark> wpwrak: "same point constraints seem to come apart when it goes red :("
<DocScrutinizer05> iirc aka modal vs non-modal
<whitequark> when it's red, the solver can't do anything, not even propagate point-coincident constraints
<DocScrutinizer05> (though I think that had another meaning, about focus grab)
<whitequark> you aren't supposed to do anything in that mode except fix them
<whitequark> wpwrak: "nice that one can select constraints directly. not so nice: if two share the same indication, one sees only one"
<whitequark> you can hover constraints in the browser window
<whitequark> and you get a highlight in the graphics window
<whitequark> so you can distinguish them by the name
<whitequark> you can also right-click on points and select "delete point-coincident" if that helps
<whitequark> DocScrutinizer05: yes modal is about focus
<whitequark> re non-multiwindow UI: I have no especial objection to that, but the architecture I inherited makes that hard
<DocScrutinizer05> can't recall which program allowed selection of either multiwindow or one-window (tiled) GUI
<whitequark> eh plenty of programs have something like "dock"
<DocScrutinizer05> checked eagle but can't find it there. gimp maybe?
<whitequark> gimp yes
<DocScrutinizer05> whitequark: can you snap windows into other windows?
<whitequark> no
<DocScrutinizer05> k, nice try
<whitequark> something to keep in mind is that i have to support three platforms
<whitequark> win32 cocoa and gtk
<whitequark> so tricks like snapping windows onto others need quite a lot of work to implement
<DocScrutinizer05> yeah
<DocScrutinizer05> Qt?
<DocScrutinizer05> not a suggestion but a question
<whitequark> Qt is shit on OS Ч
<whitequark> OS X
<DocScrutinizer05> so I gather it doesn't use qt
<whitequark> not the library itself but the UI it creates
<whitequark> no, I use native win32 and cocoa interfaces on those platforms
<whitequark> thats the only way to get a *good* UI
<DocScrutinizer05> yep, prolly right
<DocScrutinizer05> eagle "recently" switched to Qt and I have to say I'm not impressed much, even on linux
<whitequark> "recently"?
<whitequark> it was like a decade ago at least
<DocScrutinizer05> like maybe a year ago
<whitequark> no
<DocScrutinizer05> err
<whitequark> a year ago they switched from qt3 (iirc) to qt5
<DocScrutinizer05> aaah k
<whitequark> might have been qt4 somewhere in between, unsure. but eagle always used qt
<DocScrutinizer05> didn't know it was Qt already
<whitequark> qt5 has different rendering
<DocScrutinizer05> anyway looks like shit now
<whitequark> show me a screenshot. prolly your system is misconfigured
<DocScrutinizer05> and still no *decent* keymapping features, particularly for mousebuttons etc
<whitequark> s/mis/not-/
<qi-bot> whitequark meant: "show me a screenshot. prolly your system is not-configured"
<whitequark> yes. no keymapping. but that's not qt's fault, eagle just has a bad ui
<DocScrutinizer05> yep, keymapping is a genuine eagle fsckup
<DocScrutinizer05> you can map keys, but not mousebuttons etc
<DocScrutinizer05> also the icons of editr window are soooo yuck
<whitequark> your paste is just "/srv/mirrors/devuan/files.devuan.org/"
<DocScrutinizer05> damn!!
<whitequark> wpwrak: looked at your "wedge", it looks reasonable to me
<DocScrutinizer05> wstaw,org cocks up once again
<DocScrutinizer05> prolly was eagle which even makes screenshot app act funny
<DocScrutinizer05> but honestly look at those menus!
<DocScrutinizer05> YUCK!
<DocScrutinizer05> I guess what I don't like the most about them is the white background
<DocScrutinizer05> I prolly need that Qt configurator to set up such stuff?
doomlord_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<whitequark> errrr what's wrong with that? seems ok to me
<whitequark> same as qt5 looks over here
<whitequark> iirc there's a switch to get the old toolicons too
<whitequark> Options -> User Interface → Classic icon style
<DocScrutinizer05> duh!
<DocScrutinizer05> the menus still look strange with that white background
<whitequark> do you use kde?
<DocScrutinizer05> yep
<whitequark> systemsettings → application style
<whitequark> eagle should respect that
<DocScrutinizer05> well, seems it doesn't?
<whitequark> what do you set there?
<DocScrutinizer05> or is that eagle specific?
<whitequark> no that's systemwide
<DocScrutinizer05> all my other menus look different in all apps
<whitequark> mhm, can you run eagle from console and show me any messages it prints?
<DocScrutinizer05> since otherwise the eagle menus wouldn't look strange to me ;-)
<DocScrutinizer05> sure
<DocScrutinizer05> doesn't print anything there
<DocScrutinizer05> jr@saturn:~> ~/eagle-7.5/bin/eagle -->zilch
<whitequark> mm
<whitequark> and are you running kde4 or kde5?
<DocScrutinizer05> 4
<whitequark> ohhhh
<whitequark> that's why
<DocScrutinizer05> ahaaa
<whitequark> systemsettings4 doesn't set the right vars for qt5
<DocScrutinizer05> *sigh* I hate that shit
<DocScrutinizer05> Qt5, honestly now? how many more versions will they need until they go "stable"
<whitequark> never?
<whitequark> requirements are ever-changing
<DocScrutinizer05> what a shit
<whitequark> well, no, not really
<whitequark> the major reason for qt5 incompatibility is that all its drawing operations were redone in terms of GLES
<DocScrutinizer05> so how does API care?
<whitequark> there are very few breaking API changes between qt4 and qt5, mostly with good reason
<whitequark> e.g. reducing hardcoded x11 stuff
<DocScrutinizer05> instead of stabilizing stuff, each new version of KDE/Qt3/4/5 seems to introduce unique new bugs and problems
<DocScrutinizer05> while keeping the old ones. or at least new bugs are more than the old abandoned ones
<whitequark> the behavior you dislike right now is not a bug
<whitequark> it's the same problem as e.g. running gtk apps on kde54
<DocScrutinizer05> KDE3 worked, KDE4 is crap, I'm 'really looking forward'¡ to KDE5
<whitequark> *on kde4
<DocScrutinizer05> but yeah, my distro here is already almost 2 years old, how dare I
<whitequark> yes. it's full of security bugs, because it's written in shitty c
<DocScrutinizer05> the distro? Qt? KDE?
<whitequark> the distro
<whitequark> X11 isn't even "full" of security bugs, it IS a security bug, like it's literally impossible to write a robust screenlocker for X11
<DocScrutinizer05> yeah, so let's discard it and get wayland shit instead
<whitequark> yes
<whitequark> X11 should have been dumped into a trashcan decades ago
<DocScrutinizer05> and when stuff like VNC finally starts working again, I bet they already have some new leete shit we *must* adopt
<whitequark> it's bad at drawing stuff, it's bad at window management, it has nonexistent security
<whitequark> there is absolutely nothing x11 is good at
<DocScrutinizer05> it works
<whitequark> nah.
<whitequark> it doesn't.
<DocScrutinizer05> here it does
<whitequark> it """works""" because of a pile of fragile hacks that happens to appear like it works some of the time
<DocScrutinizer05> unless some crappy Qt5 stuff comes along
<whitequark> like most of unix, really
<DocScrutinizer05> that's the way I like it
<whitequark> then don't complain when others fix your shitty OS
<DocScrutinizer05> I do
<DocScrutinizer05> cascade of ADHS youngsters
<whitequark> yes, incompetent old farts are much better
<DocScrutinizer05> indeed
<whitequark> </sarcasm>
<DocScrutinizer05> particularly when the attributed "incompetent" comes from such youngsters of the sort of Poettering et al
<whitequark> well, you know I am not fond of poettering
<whitequark> his "fixes" aren't any better than the old broken way
<DocScrutinizer05> there's an army of those nitwits
<DocScrutinizer05> trying to "fix UNIX"
<whitequark> that doesn't mean that the old broken way is any good though
<whitequark> yes, because practically every part of UNIX is broken by design. it would take an army to fix it, indeed
<DocScrutinizer05> please roll your own OS then, leave unix alone
<whitequark> half of the core APIs are better in *Windows*
<DocScrutinizer05> then fix windows please!
<larsc> I just wanted to say, lets all switch to windows
<whitequark> Debian/kWindowsNT is not a bad idea
<whitequark> winnt is a great kernel
<whitequark> windows userspace is shit too though
<DocScrutinizer05> lemme put it this way: as long as those leet devels are not capable to improve on the old while keeping 100(!)% backward compatibility, they are simply not competent enough to qualify to "fix unix/linux/whatever"
<whitequark> you cannot keep 100% backward compatibility
<whitequark> your requirements are impossible.
<DocScrutinizer05> you just diqualified
<DocScrutinizer05> yourself
<whitequark> it's just "get off my lawn" masqueraded as "objective requirements"
<whitequark> and no, i won't get off your lawn, and i won't appease your stockholm syndrome either
<DocScrutinizer05> indeed get off my lawn, instead of telling me "this wayland stuff is much better, just forget about all the tools you had so far, they don't work anymore with this new leete wayland. Incl VNC and whatnot"
wej has joined #qi-hardware
<DocScrutinizer05> replace "wayland" by "systemd" or whatever you like, in last statement
<DocScrutinizer05> I don't see a single "requirement" that e.g. Qt4 made feasible and I missed it in Qt3
<DocScrutinizer05> I don't see any security issues with my X11 either
<whitequark> and.... let me find the locker ones
<DocScrutinizer05> and for sure I don't need any systemd messing up my whole system, to cure dunno what, boottime?
<whitequark> https://www.jwz.org/blog/2015/04/i-told-you-so-again/ by the author of xscreensaver no less
<whitequark> this is a problem *in x11*, because x11 has no robust way for an application to say "i'm the screen locker"
<whitequark> well, no way at all, you can only try to fake it, badly
<DocScrutinizer05> sounds like an XY problem of sorts. Somebody can't implement some crap so the underlying infra must be broken. Maybe the approachis broken and nobody really needs that crap he wants to implement?
<whitequark> yes. no one needs screen lockers.
<whitequark> obviously.
<whitequark> have you considered actually thinking about use cases that do not perfectly match the one thing you want to do?
<DocScrutinizer05> I actually don't need, and even if I did, it seems they worked so far
<DocScrutinizer05> I thinkignoring usecases is a privilege of Poettering and friends
<DocScrutinizer05> a pretty sane rationale to nuke unix completely a reassemble it in a completely different incompatible way, to make stuff like screen lockers with session switching, audio during bootmenu, and multiseat work
<pigeons> need the qr codes and http servers in the init system too
<DocScrutinizer05> yeah, systemd is already there to meet your needs
<whitequark> i can't stand systemd
<whitequark> poettering is just as incompetent as those before him, just with more bloat
<DocScrutinizer05> btw lovely hubris by wayland devels when they think their code would immenently have less CVEs than X11
<DocScrutinizer05> and actually screenlocker *is* an XY problem, you can't implement a decent screenlocker on app level without support from the display/window-manager. So better implement it outside and above of the whole display-manager system tight away
<DocScrutinizer05> right away*
<whitequark> yes, that's exactly what wayland does. the screenlocker is implemented in the compositor itself
<DocScrutinizer05> *shrug*
<DocScrutinizer05> no argument to go for wayland
<DocScrutinizer05> actualy I think implementing the screensaver *into* the display manager is flawed design
<whitequark> not screensaver, no
<whitequark> kde5 doesn't have screensavers anymore
<DocScrutinizer05> it should be a system unentangled with display manager
<whitequark> which actually pisses me off a lot but security wise it makes sense
<DocScrutinizer05> once a screensaver was exactly that. While a login screen was something entirely different, by purpose as well as implementation
<whitequark> yes. screensavers and screenlockers are completely different classes of software that were wrongly intermingled
<DocScrutinizer05> mixing up the two is arguably not the right thing to do
<DocScrutinizer05> (screenlocker) must disable the normal display/window-manager's functions completely, incl kbd input and whatnot. Like switching to a new console (ctrl-alt-F9). Even providing support in display manager for an app to take over completely is a security risk since then any arbitrary such app could take over from display manager and intercept user's inputs
<whitequark> hence wayland removes the XTEST functionality, used by x screenlockers
<whitequark> and also, incidentally, vnc servers
<DocScrutinizer05> you are aware why on windows you're supposed to press ctrl-alt-del to login, are you?
<whitequark> yes
<whitequark> alt+sysrq+k on linux
<whitequark> that solves a slightly different problem: someone impersonating a login screen
<whitequark> so you need something to be intercepted by the kernel, before it ever reaches *any* userspace
<DocScrutinizer05> hmm, I think on ISA PC that's even deeper, you can't block it at a softzware level, causes a NMI iirc
<DocScrutinizer05> alt-ctl-del that is
<whitequark> on anything 32-bit it's just a keyboard input, has to be so or you couldn't login from USB keyboards
<DocScrutinizer05> I dunno, it actually makes sense that there's no IRQ line/wire in the kbd cable so something has to decode the keycodes
<whitequark> well with PS/2 you could decode that in hardware if you wanted
<DocScrutinizer05> maybe I'm wrong on the hw NMI thing
<whitequark> thats an FSM that compares three bytes, not too hard
<DocScrutinizer05> aaaah then prolly that was it
<whitequark> no idea if it actually worked like that, just speculating
<DocScrutinizer05> I guess there must be a reason for ps/2 jacks _still_ existing, and I tink I faintly recall I heard sth ölike this
<whitequark> that NMI thing certainly don't happens on any 32-bit systems, that much i know
<DocScrutinizer05> once in the PC pleozen there must have been an IRQ to recover a locked up system
<whitequark> ps/2 jacks mostly stopped existing a few years ago, you'd be hard pressed to find such a motherboard
<whitequark> even vga is practically dead
<DocScrutinizer05> hmm, I bought a PC 1 year ago which still has them
<DocScrutinizer05> new
<DocScrutinizer05> there's a number of funny "cruft" in standard ISA PC mobos
<DocScrutinizer05> A20-gate for example ;-)
<whitequark> ugh
<whitequark> what pisses me off the most is that new SoCs are just as crufty, actually probably even more so
<whitequark> just hard IP slapped together by some intern
<whitequark> have you heard that intel laid off most of their verification team?
<DocScrutinizer05> wow, great!
<DocScrutinizer05> to start with: they had any?
<DocScrutinizer05> ;-D
<whitequark> yes, they had a massive amount of people dedicated to that
<whitequark> which is why they were able to ship the monster that is x86 and have it work at all
<pigeons> i use ps2 ports for keyboards and mice to have more available usb ports
infobot has quit [Ping timeout: 260 seconds]
<whitequark> DocScrutinizer05: have you tried out the dxf import feature yet?
<DocScrutinizer05> nope
<DocScrutinizer05> friggin bot went south again
jwhitmore has quit [Ping timeout: 260 seconds]
wildlander has quit [Quit: Saliendo]
kilae has quit [Quit: ChatZilla 0.9.92 [Firefox 46.0.1/20160502172042]]
jwhitmore has joined #qi-hardware
jwhitmore has quit [Ping timeout: 252 seconds]
<wpwrak> whitequark: hmm, seems that gtk_window_set_keep_above is only advisory, and you're not guaranteed that it works
<wpwrak> i wonder why the graphics window keeps in crawling on top, though. you're not calling gtk_window_present anywhere.
<whitequark> wpwrak: yes. it's advisory. X11 does not have any way to make that mandatory, your WM is supposed to make sure of that
<whitequark> and it keeps crawling on top perhaps because you're clicking on it?
<wpwrak> the WM is only supposed to take it into consideration :)
<wpwrak> clicking on a window itself shouldn't raise it
<wpwrak> e.g., i can put an xterm under the browser window and click on it all day, and nothing happens
<whitequark> that's windows of a different application though
<wpwrak> or even with this xchat (under an xterm)
<whitequark> try doing that with two browser windows to get an accurate comparison
<wpwrak> a browser is a little universe onto itself ;-)
<whitequark> well, anything else that has two nonmodal windows
<whitequark> gimp
<wpwrak> if it's something gtk does by default, then there must be a way to turn it off. now, how do they call this ...
<whitequark> that's not gtk, that's your WM...
<wpwrak> of course, everyone is looking for the opposite ... how to make MY window dominate all the rest of the pile ... :(
<whitequark> gtk has no say in window ordering at all
<wpwrak> i'm trying to think of a bare X11 program that opens multiple windows ...
<wpwrak> hard to find these days. but it would surprise me a bit if the WM would get involved if it doesn't care about auto-raising if windows are not from the same application
<whitequark> I'm sure you'll manage to open two ;)
<wpwrak> opened two, and as expected, fvwm doesn't get involved
<whitequark> hmmmm no idea then. i continue to insist that your wm should just respect the "above" flag
<whitequark> though, if you produce a patch that does work for you, i'll probably merge it
<wpwrak> hmm, tried to TW->set_transient_for(*GW); but alas, no effect
<wpwrak> the "push to front" effect of GW is very strong
<wpwrak> and it also does this against windows from other applications
<whitequark> i definitely never added such behavior intentionally
<wpwrak> ... which isn't something gtk does on its own either (tried with some gtk apps of my own)
<whitequark> that have two toplevel windows?
<wpwrak> e.g., i can edit around in fped all day and it never tries to displace other windows
<wpwrak> i'm testing single-window gtk vs. xterm
<wpwrak> solvespace's GW always goes on top immediately. my gtk apps never do
<whitequark> i'm pretty sure this is related to having two windows in one application
<wpwrak> i closed TW, and it still happens
<whitequark> oh, so GW is raised even against other applications?
<whitequark> oh, i see
<whitequark> are you building with GTK2 or GTK3?
<wpwrak> libgtk-x11-2.0.so.0 and libgtkmm-2.4.so.1
<whitequark> ok, so gtk2
<whitequark> hm.
<whitequark> thats very bizarre
<wpwrak> it seems to be caused by drawing, not the input itself. e.g., if i type "1", which seems to be ignored, nothign happens
<whitequark> thats not mouse
<wpwrak> ah no, G (if just toggling state) doesn't raise it either
<whitequark> yes, this is related to mouse
<wpwrak> yeah, just thought it may be input in general
<whitequark> try commenting out line 553 and 573 in gtkmain.cpp
<wpwrak> it's also not mouse in general :)
<wpwrak> wheel and right-click do nothing
<wpwrak> yup, that eliminates the raising. unless i double-click left
<whitequark> let's say you double-click left
<whitequark> and it doesn't open an editor
<whitequark> still happens?
<wpwrak> yes
<wpwrak> so it must be something that happens when SS processes the mouse event
<wpwrak> let's find out what ...
<wpwrak> btw, i'm getting a bunch of warnings when compiling. known issue ?
<whitequark> which?
<wpwrak> oh, a few dozen. so it should compile without warnings ? here's an example: https://neo900.org/stuff/paste/yaeVo4ji
<whitequark> ohh
<whitequark> your gtk is too old
<whitequark> that's nothing i can fix, it's a gtk issue
<whitequark> are there others?
<wpwrak> i think so. i'll do a full build later and send you the output
<whitequark> generally i keep it warning-free, and use -Wall, so yeah
<wpwrak> good. that's what i thought :) wish everyone had that attitude ;-)
<whitequark> hm, actually -Wall is not in the build flags for some reason
<wpwrak> hmm, this may get tricky. left click on "empty" did raise the window. commenting out the call to SS.TW.HideEditControl(); in GraphicsWindow::MouseLeftDown (mouse.cpp) make it not raise the window in this case. however, if the click selects an object, the window still raises
<wpwrak> aaah !!! ;-)
<whitequark> .... oh
<whitequark> GW->raise();
<wpwrak> gtk/gtkmain.cpp HideTextEditControl(void)
<whitequark> so i do in fact call it explicitly
<wpwrak> yeah ;-)
<whitequark> ok that's very simple to fix
<whitequark> wrap it in if(TW->get_overlay().is_editing()) {}
<whitequark> I'll commit it soon
<wpwrak> commented it out and it makes things a lot smoother. now, if a dialog comes up, the browser still gets pushed down. let's see if this can be fixed, too ...
<wpwrak> mmh, no such luck :(
<wpwrak> tried to do it with set_transient_for
<whitequark> fwvm probably doesn't care about that either
<wpwrak> maybe it needs to be called at a specific time and i'm doing it too late. let's see ..
<wpwrak> nope, no effect
<wpwrak> a dialog also makes GW raise above xterms. though that looks less unexpected. let's see if this is really something "normal" ...
<whitequark> wpwrak: does replacing raise() with show() do something nasty on your WM?
<whitequark> hm, nevermind, I can just remove that
<whitequark> doesn't seem to have any ill effect