Re: [racket-users] Splitting up a GUI source file?
Thank you for the paper. I had come across units several times, but I could never figure out *what* their intention was from the documentation. The paper has at least made their motivation clear, I still have to figure out how to actually use this feature now. On Friday, March 23, 2018 at 6:33:27 PM UTC+1, Matthias Felleisen wrote: > > ... > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Splitting up a GUI source file?
> May be relevant > > https://pkgs.racket-lang.org/package/spreadsheet-editor Indeed, I got part way through working with that package for this exact purpose but ran into glitches. The main thing is just a lack of documentation. At this point, I am favoring the idea of borrowing qresults-list% from the Activity Log2 application as mentioned previously on this list (quoted below.) Unfortunately, I probably won't have time to get back to the project until May. On Mar 5, 2018, at 4:00 PM, Alex Harsanyi wrote: > If you want to look at a possible implementation, I wrote a wrapper around > list-box% for exactly the purpose of showing SQL query results in a > list-box%. It supports sorting, adding, deleting and updating individual > rows, and you can also reorder and resize columns and this layout is saved > and can be restored: > >https://github.com/alex-hhh/ActivityLog2/blob/master/rkt/widgets.rkt#L982 > > The name of the class is `qresults-list%` and you can find usage examples of > it throughout the application. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Splitting up a GUI source file?
May be relevant https://pkgs.racket-lang.org/package/spreadsheet-editor s. On Fri, Mar 23, 2018 at 5:09 PM, James Platt wrote: > > > I am trying to create a GUI program, my problem is that the source code > for the > > GUI portion is growing out of control and I don't know how to split it > up. > > I'm not sure if this will really answer your question but you may want to > look at some code from MrEd Designer and see how it splits stuff up. It > generates all the GUI code in a file which you then include in a file with > the logic you write. Following this approach, you could probably have more > than one GUI file which you could include in your top level file. > > > > > Here is some background info: the GUI is basically just a specialised > frontend > > to a database, the users clicks some stuff, the corresponding query is > > constructed and sent off to SQLite using the db library. > > Actually, I've been thinking about learning about how to create MrEd > Designer widgets in order to add some elements which would be useful for > database clients. This would include editable tables, like you mention. > > James > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Splitting up a GUI source file?
SHORT: You may wish to *look* at the first units paper at https://www2.ccs.neu.edu/racket/pubs/#pldi98-ff because what you describe is almost exactly the example from that paper. Just read the example section. If you like what you see, jump into the docs. ;; - - - SOMEWHAT LONGER: People usually shift a compile-time organization to a run-time one when confronted with this situation, that is, the desire to split such things in a static, tree-shaped world. The code then exports functions that when called with proper callbacks create the desired code and perform properly. What you give up then, is a compile-time confirmation that these things match up. Units solve this with support for mutually referential components. To some extent they are independent of modules and you can use modules with units just fine. Historically, units were our first module system but getting syntax export/imports right is easier with first-order modules. — Matthias > On Mar 23, 2018, at 11:39 AM, HiPhish wrote: > > Hello Racketeers, > > I am trying to create a GUI program, my problem is that the source code for > the > GUI portion is growing out of control and I don't know how to split it up. > > Here is some background info: the GUI is basically just a specialised frontend > to a database, the users clicks some stuff, the corresponding query is > constructed and sent off to SQLite using the db library. > > The layout is to have one main window with a tab view. The application is > supposed to manage a small library, so each tab shows either the books, the > users, or the rentals. Here is a simple tree-view of the GUI: > > main window > | > |-- main tab view > | > |-- Books pane > | | > | |- List view of books (a table) > | |- Button to add a new book > | |- Button to remove a book > | |- Button to rent out a book > | > |-- Users pane > | | > | |- List view of users (a table) > | |- Button to add a new user > | |- Button to remove a user > | > |-- Rentals pane > | > |- List current rentals (a table) > |- Button to remove a rental > > > I might reconsider the rentals part, but that's not relevant at the moment. My > problem is that even though the three panes don't need to know anything about > each other, they need to know about their parent (the main tab view), I cannot > split the code into a module hierarchy like the tree. > > (define main-window (new frame% [label "Library"])) > (define main-tab-view (new tab-panel% [parent main-window])) > > (define books-panel (new vertical-panel% [parent main-tab-view])) > (define books-table (new list-view% [parent books-pane])) > (define books-buttons-pane (new horizontal-pane% [parent books-panel])) > (define add-button (new button% [parent books-buttons-pane])) > (define remove-button (new button% [parent books-buttons-pane])) > (define rent-button (new button% [parent books-buttons-pane])) > > > And so on. This isn't much code, but add in all the callbacks and events, and > repeat that for all the three views, and the code quickly starts adding up. > How should I break it up into smaller modules? > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Splitting up a GUI source file?
> I am trying to create a GUI program, my problem is that the source code for > the > GUI portion is growing out of control and I don't know how to split it up. I'm not sure if this will really answer your question but you may want to look at some code from MrEd Designer and see how it splits stuff up. It generates all the GUI code in a file which you then include in a file with the logic you write. Following this approach, you could probably have more than one GUI file which you could include in your top level file. > > Here is some background info: the GUI is basically just a specialised frontend > to a database, the users clicks some stuff, the corresponding query is > constructed and sent off to SQLite using the db library. Actually, I've been thinking about learning about how to create MrEd Designer widgets in order to add some elements which would be useful for database clients. This would include editable tables, like you mention. James -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Splitting up a GUI source file?
Hello Racketeers, I am trying to create a GUI program, my problem is that the source code for the GUI portion is growing out of control and I don't know how to split it up. Here is some background info: the GUI is basically just a specialised frontend to a database, the users clicks some stuff, the corresponding query is constructed and sent off to SQLite using the db library. The layout is to have one main window with a tab view. The application is supposed to manage a small library, so each tab shows either the books, the users, or the rentals. Here is a simple tree-view of the GUI: main window | |-- main tab view | |-- Books pane | | | |- List view of books (a table) | |- Button to add a new book | |- Button to remove a book | |- Button to rent out a book | |-- Users pane | | | |- List view of users (a table) | |- Button to add a new user | |- Button to remove a user | |-- Rentals pane | |- List current rentals (a table) |- Button to remove a rental I might reconsider the rentals part, but that's not relevant at the moment. My problem is that even though the three panes don't need to know anything about each other, they need to know about their parent (the main tab view), I cannot split the code into a module hierarchy like the tree. (define main-window (new frame% [label "Library"])) (define main-tab-view (new tab-panel% [parent main-window])) (define books-panel (new vertical-panel% [parent main-tab-view])) (define books-table (new list-view% [parent books-pane])) (define books-buttons-pane (new horizontal-pane% [parent books-panel])) (define add-button (new button% [parent books-buttons-pane])) (define remove-button (new button% [parent books-buttons-pane])) (define rent-button (new button% [parent books-buttons-pane])) And so on. This isn't much code, but add in all the callbacks and events, and repeat that for all the three views, and the code quickly starts adding up. How should I break it up into smaller modules? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.