aboutsummaryrefslogtreecommitdiff
path: root/gtk.c (follow)
Commit message (Collapse)AuthorAge
...
* Fix GTK puzzle resizing, *again*.Simon Tatham2015-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jonas Kölker points out that commit a800ff16b (which fixed a bug in the previous attempt) left in another bug: if the puzzle size was changed while the window was maximised, the system would fail to recompute the tile size and would redraw completely wrongly. So it's not optional after all to run midend_size(), even if the drawing area size hasn't changed. I've reverted that code to be unconditional, and now only the refresh of the Cairo-side backing store system is conditionalised - and that's conditionalised on changes to either the size of the actual window _or_ the size of the contained pixmap. (The latter should defend against redraw failure in the case where the puzzle aspect ratio changes, so that neither the window size nor the tile size changes but a recentre is still needed.) I _think_ this now fixes all the cases of resizing: this time I've tested making an unmaximised puzzle window bigger or smaller, and within a maximised window, forcing the puzzle to scale up, scale down, or change its aspect ratio without changing its tile size. All work, on GTK2 and GTK3, and yet we still don't get the visible flicker on status line updates that was the reason I started fiddling with this code in the first place. (We _do_ still call configure_area on every update of the status line, at least under GTK3; that's going to cause a forced full redraw on every timer tick in Mines, which is wasteful of CPU, so it would still be nice to find a better way of identifying the cases in which no resizing at all was necessary and we could avoid renewing the game drawstate. But the current code at least doesn't have any display _errors_ that I know of, which is an improvement on its previous state.)
* Fix two memory leaks in GTK frontend.Jonas Kölker2015-10-18
| | | | | | | | - The file selector for loading and saving gets a g_free(). - The handling of saving (menu_save_event) gets an sfree(). - It's also slightly restructured to prevent future errors. - menu_load_event was already structured to prevent this error. - The OLD_FILESEL code seems to not need a g_free().
* In GTK frontend, bind mouse8/mouse9 to undo/redo.Jonas Kölker2015-10-14
| | | | | | These button codes are generated by the back/forward button pair on the sides of some mice, and web browsers treat these as the back and forward actions in the page history.
* GTK 3 cleanup: stop using GtkDialog for config boxes.Simon Tatham2015-10-04
| | | | | | | | | | | It's becoming annoying to keep working within the increasing restrictions on GtkDialog, in particular the fact that not only do we have to let it have complete control of the button area, but also it's not clear whether we can intercept a press of the 'OK' button and display an error message rather than ending the dialog. So, as I did in PuTTY, I'm resorting to using an ordinary GtkWindow with controls I laid out myself.
* GTK 3 cleanup: use GtkAboutDialog for the About box.Simon Tatham2015-10-04
| | | | | | This is again easier than faffing about doing it manually, and as an added bonus, we get to put the largest of our icons in the box as a logo :-)
* GTK 3 cleanup: use GtkMessageDialog for message_box().Simon Tatham2015-10-04
| | | | | | This is a lot easier than faffing about setting up a dialog box ourself, and also avoids direct access to GtkDialog's action area (deprecated in GTK 3.16).
* GTK 3.16 deprecation: stop using gtk_misc_set_alignment.Simon Tatham2015-10-04
| | | | | The new equivalent is gtk_label_set_{x,y}align. But we can't use that in all GTK 3 builds, because it's very new.
* Fix switching to a larger puzzle size under GTK 2.Simon Tatham2015-10-03
| | | | | | | | | | | | | Commit 8b491946e had a bug: configure_area stopped doing most of its work if the new size already matched fe->w and fe->h, but in fact the GTK2 resize_fe() _already_ set up fe->w and fe->h for the new size. I managed not to notice, because I checked it all worked on GTK 3 but only tested resizing to a _smaller_ puzzle on GTK 2. Ahem. Now we don't change fe->w and fe->h at all until configure_area is called. Also, we initialise them to dummy values at setup time, so that configure_area won't compare the new size with uninitialised data.
* Insert a manual reference in the default status bar text.Jonas Kölker2015-10-03
| | | | | | To guide developers to the resources they need. [actual wording tweaked by SGT]
* GTK 3 port: don't turn off drawing area double buffering.Simon Tatham2015-10-03
| | | | | | | | | | | | I think I did this in GTK2 on the basis that our server-side cache pixmap was double-buffering enough for us - any puzzle which erased a big area with a background rectangle and then redrew over the top of it would do so only on the off-screen pixmap, and the updates would only be copied to the visible window after it was all done. In GTK3, I don't think there's any need - this is all the usual way things are done anyway, as far as I can see. So I've turned this call back off, at least until I hear of a reason why I need it again.
* GTK 3 port: change API functions for widget sizing.Simon Tatham2015-10-03
| | | | | set_usize is deprecated, and get_preferred_size is the GTK 3 thing we should use in place of size_request.
* GTK 3 port: use GtkBox directly, not GtkHBox and GtkVBox.Simon Tatham2015-10-03
| | | | | I've done this by #defining the old names in terms of the new ones, because the old ones are still more concise!
* GTK 3 port: be prepared not to use GtkStock.Simon Tatham2015-10-03
| | | | | | GTK 3 has deprecated it in favour of just making you specify fixed strings as button labels, which seems like a step backwards to me but there we go.
* GTK 3 port: use GdkRGBA for the window background colour.Simon Tatham2015-10-03
| | | | | Suits our internal API better, anyway, with RGB components being floats ranging from 0 to 1.
* GTK 3 port: stop getting default bg colour from the window style.Simon Tatham2015-10-03
| | | | | GTK3 window styles don't reliably provide one, so we have to fall back to just making one up.
* GTK 3 port: condition out the complicated window resize code.Simon Tatham2015-10-03
| | | | | | | | | | | | | | | | | | | | | | | | In GTK 2, we had a big pile of horrible code to deal with the fact that it's very hard to open a window in such a way as to make it easy to resize smaller as well as bigger. Essentially, we'd open the window with the drawing area's minimum size request set to the desired _initial_ window size; then we'd wait until GTK had finished creating other window components (menu bar, status line) and the window's size allocation had settled down, and finally reduce the size request to the real minimum size so that now the window was resizable in both directions. This also involved some deliberate checking of the Ubuntu Unity GTK extension which steals the menu bar and put it elsewhere (see commit 8f8333a35), to avoid us waiting forever for a menu bar that wasn't going to show up. But in GTK3, this has all become actually sensible! All we now have to do is to set the window's geometry hints to indicate the drawing area itself as the base widget (probably a good plan anyway), and then we can set the initial size using gtk_window_set_default_geometry() and resize it later using gtk_window_resize_to_geometry(). So now we can completely condition out all of the previous horrors, and consider them to be legacy GTK2 compatibility code only. Phew.
* GTK 3 port: provide a 'draw' handler.Simon Tatham2015-10-03
| | | | | | This is what GTK 3 uses in place of 'expose_event'. Also I've arranged here for my internal USE_CAIRO_WITHOUT_PIXMAP setting to be enabled in GTK3, as well as in GTK2 with deprecated functions disabled.
* GTK 3 port: use GtkGrid as an alternative to GtkTable.Simon Tatham2015-10-03
| | | | | | This also involves setting some "hexpand" properties on the widgets contained in the GtkGrid, to achieve effects which GtkTable did by setting flags in gtk_table_attach.
* GTK 3 prep: use g_timeout_add, not gtk_timeout_add.Simon Tatham2015-10-03
|
* GTK 3 prep: use GTK instead of GDK window-icon functions.Simon Tatham2015-10-03
| | | | We now build cleanly with -DGDK_DISABLE_DEPRECATED.
* GTK 3 prep: make the server-side backing pixmap optional.Simon Tatham2015-10-03
| | | | | | When GDK_DISABLE_DEPRECATED is defined, we now don't have fe->pixmap; instead we just maintain our client-side window contents in fe->image, and draw from there directly to the window in the expose handler.
* GTK 3 prep: use gtk_radio_menu_item_get_group().Simon Tatham2015-10-03
| | | | | Replaces the previous deprecated spelling. We now build cleanly with -DGTK_DISABLE_DEPRECATED.
* GTK 3 prep: use GtkComboBox for drop-down lists.Simon Tatham2015-10-03
| | | | The previous GtkOptionMenu was long since deprecated.
* GTK 3 prep: use the glib names for base object types.Simon Tatham2015-10-03
|
* GTK 3 prep: use GTK_KEY_* constants.Simon Tatham2015-10-03
|
* GTK 3 prep: use accessors instead of direct field access.Simon Tatham2015-10-03
| | | | We now build cleanly with -DGSEAL_ENABLE.
* Fix packing direction of config boxes.Simon Tatham2015-10-03
| | | | | | | We were packing the GtkTable into the dialog's content area using gtk_box_pack_end, which had the slightly silly effect that resizing the config box vertically would keep all the controls aligned to the _bottom_ rather than the top.
* Don't refresh backing store on a no-op configure event.Simon Tatham2015-10-03
| | | | | | | | | | | | | | | | | Sometimes, we can get a "configure_area" event telling us that the drawing area has changed size to the same size it already was. This can happen when we change puzzle presets in a way that doesn't change the size, and also sometimes seems to happen as a side effect of changing the text in the status line. In that situation, it's a waste of effort - and can cause visible on-screen flicker - to throw away the window's backing image and pixmap and regenerate them from scratch. So now we detect a non-resize and avoid doing all that. The only thing we retain unconditionally in configure_area is the midend_force_redraw, because that's the place where a puzzle redraw is forced when changing presets or loading a new game.
* Fix puzzle window resize behaviour on Unity.Simon Tatham2015-01-04
| | | | | | | | | | | Unity hijacks the menu bar and prevents it from appearing in the main puzzle window. And we wait for the menu bar to appear before reducing the puzzle drawing area's size request. These two behaviours go together badly. Fixed by detecting the extra GTK property that the Unity patches invented, and using that to know whether to expect the menu bar to show up at all.
* Remove another erroneous GINT_TO_POINTER.Simon Tatham2014-11-29
| | | | | This one shouldn't have been there at all - it had a pointer argument already, not an int.
* Fix a GINT_TO_POINTER that was back to front.Simon Tatham2014-11-29
| | | | | Spotted by clang, which I just tried building this codebase with out of curiosity.
* Introduce some extra testing and benchmarking command-line options toSimon Tatham2013-04-11
| | | | | | | | | | | | | | | | the GTK front end, plus a 'make test' target in the GTK makefile which uses them to automatically generate 100 puzzles for each game at each preset configuration, test-run them back through the solver without their aux_info to ensure that can cope, and produce an HTML box plot of game generation times for each preset. As part of this work I've removed the TESTSOLVE mechanism from r9549, since the new --test-solve option does the same thing better (in that when something goes wrong it prints the random seed that caused the problem). [originally from svn r9825] [r9549 == 5a095b8a08fa9f087b93c86aea0fa027138b028d]
* Actually do what the comment says at the top of main() regarding notSimon Tatham2012-12-28
| | | | | | | | bombing out due to an option that we don't recognise but GTK will. Somehow my basically workable plan had been completely nullified by putting the error check in the wrong place. [originally from svn r9733]
* Fix overnight build failure last night, by making the new call toSimon Tatham2012-11-21
| | | | | | | | | | | | gtk_widget_get_allocation conditional on GTK being new enough to have that function. I'm assuming until someone proves otherwise that if it isn't that new, then it also isn't one of the versions of GTK which exhibit the bug which that call was working around (since gtk_widget_get_allocation came in 2.18, and the problem seems to have arisen since 2.20). [originally from svn r9712]
* Work around an annoying GTK behaviour I noticed the other day on mySimon Tatham2012-11-20
| | | | | | | | | | | | | | | | Ubuntu 12.04 machine. What seems to happen is that we set up a window containing a menu bar, a drawing area and a status bar, and set the size of the drawing area; then the window is displayed _without_ the menu bar; then we reduce the drawing area's size request to (1,1) to let the user resize the window smaller; and now GTK gets round to constructing the menu bar, and the drawing area helpfully shrinks a bit to make room for it. My fix is to set a 'shrink pending' flag instead of shrinking the drawing area's size request, and defer the actual shrink operation until the menu bar and status bar are both present. [originally from svn r9711]
* Allow --save to work with --soln, causing saved game files to beSimon Tatham2011-12-28
| | | | | | written out with the Solve operation having already been performed. [originally from svn r9375]
* Fix bug in error reporting for --save caused by freeing 'realname'Simon Tatham2011-12-28
| | | | | | before the error messages wanted to use it. [originally from svn r9374]
* Fix bug in --save caused by failure to initialise ctx.error to zeroSimon Tatham2011-12-28
| | | | | | before later checking to see if an errno code was dumped in it. [originally from svn r9373]
* Fixes to r8997: firstly, move the fix out of #ifdef CAIRO so that itSimon Tatham2010-11-06
| | | | | | | | | applies to both drawing mechanisms, and secondly, make sure to paint the spare pieces of window in the _puzzle's_ background colour rather than the (sometimes slightly different) system default. [originally from svn r9021] [r8997 == 26c669a6b2892b97b4a9bc6842f633291951fdbd]
* Jonas Koelker reports that using the version of GTK currently inSimon Tatham2010-09-14
| | | | | | | | | | | | | | Debian sid (2.20.1), there's a redraw problem when the window has a different aspect ratio from the puzzle (due to resizing or maximising): pieces of the window outside the real puzzle rectangle don't get redrawn when exposed (e.g. by the drop-down menus). Introduced code to explicitly redraw the whole exposed area, including the parts that fall outside the pixmap. This makes the problem go away in my hasty test install of sid, and doesn't seem to affect the build on lenny. [originally from svn r8997]
* Patch from Mark Wooding to introduce a draw_thick_line() function inSimon Tatham2010-05-29
| | | | | | | | | | | | the drawing API, for use by Loopy. It's optional: drawing.c will construct an acceptable alternative using a filled polygon if the front end doesn't provide it. Net and Netslide previously had static functions called draw_thick_line(), whose claim to the name is less justified and so they've been renamed. [originally from svn r8962]
* Patch from Mark Wooding to (optionally at compile time) use theSimon Tatham2010-05-29
| | | | | | | | Cairo rendering library in place of GDK, which provides pretty antialiased graphics much like we get on MacOS. Inertia and Untangle are perhaps the two games most obviously improved by this. [originally from svn r8961]
* Patch from Mark Wooding to disable GTK's internal double buffering,Simon Tatham2010-05-29
| | | | | | | which I didn't know about, but which is clearly a waste of effort since we keep our own backing pixmap for the puzzle window. [originally from svn r8960]
* Patch from Mark Wooding to use GTK stock items for standard 'OK',Simon Tatham2010-05-29
| | | | | | | | 'Yes' and 'No' buttons, which means they get the standard icons that go on those button types. Also reorders yes/no boxes so that they're the GNOME standard way round. [originally from svn r8959]
* Patch from Debian, to bring the use of the X selection/clipboard inSimon Tatham2010-04-25
| | | | | | | | | line with freedesktop.org. (This is relatively simple for Puzzles, since it only writes to the clipboard and never reads it, so the question of which selection to use when is most easily dealt with by always writing to both.) [originally from svn r8929]
* Introduce, and implement as usefully as I can in all front ends, aSimon Tatham2009-12-27
| | | | | | | | | | new function in the drawing API which permits the display of text from outside basic ASCII. A fallback mechanism is provided so that puzzles can give a list of strings they'd like to display in order of preference and the system will return the best one it can manage; puzzles are required to cope with ASCII-only front ends. [originally from svn r8793]
* Patch from Frode Austvik to tinker with the GTK interface ifSimon Tatham2009-12-17
| | | | | | | | compiling gtk.c with STYLUS_BASED defined: most notably, it provides a row of numeric 'keys' made of GTK button widgets for puzzles that want a numeric keypad. [originally from svn r8783]
* Patch from Mark Wooding: when I did r7980 I had completely failed toSimon Tatham2009-06-21
| | | | | | | | | notice that there was an _official_ way to have menu items marked as selected or unselected, which is the GtkRadioMenuItem class. Replace my ad-hoc use of bullet characters with that. [originally from svn r8601] [r7980 == ae6c7381272f84c0fd398f6d3e496f571ba42ec8]
* Patch from Mark Wooding: use gdk_event_request_motions() whereSimon Tatham2009-06-21
| | | | | | | | available, which magically seems to eliminate most if not all of the update lag when dragging a point in a large (say 250-point) Untangle. I don't fully understand how this works, but it seems to! [originally from svn r8600]
* Patch from Mark Wooding: stop setting GTK_EXPAND for the x-directionSimon Tatham2009-06-21
| | | | | | | | | | | | on labels in tables. The effect is that if you resize (e.g.) Solo's configuration panel, the labels to the left of the various input boxes will remain just big enough to fit their text in, and all the extra space will be taken up by the useful part, i.e. the input boxes themselves. Previously the labels and input boxes would expand in a 1:1 ratio, causing lots of space to the right of the label text that wasn't used for anything. [originally from svn r8599]
generated by cgit v1.1 at 2026-04-25 06:44:25 +0000