Hello Lyle, Everyone :) I''ve been putting some of the stuff Lyle was telling me last week about using create after defining new widgets outside of the initialize method for an app class, in order to get them to show up. I was attempting to update the content in a tab as the values associated with the content changed over time. Iwas attempting to drive this update myself using a timed event. Due to some of the cumbersome things I came up with while trying to manually manage the UI elements in this fashion, I''m thinking there has to be a better way, and I''m thinking I stumbled onto it this morning while reading some of the documentation. Is the best way to do this to create all the top-level widgets (and their children) for an interface, and implement the update signals? Seems then I''d be able to create all the primary widgets, let the app change the values and send update signals back to the widgets and let them manage repainting themselves with the new values. Am I on the right track? if so, can anyone toss me any gems of wisdom before I try to get my head around the details? Thanks All! Twitch -- ==================================Woulds''t thou so blame the fragrant blos''ms wilting as never to''ve had her bloom?
On Aug 15, 2005, at 9:48 PM, James Stallings II wrote:> Is the best way to do this to create all the top-level widgets (and > their children) for an interface, and implement the update signals? > Seems then I''d be able to create all the primary widgets, let the app > change the values and send update signals back to the widgets and let > them manage repainting themselves with the new values. > > Am I on the right track? if so, can anyone toss me any gems of wisdom > before I try to get my head around the details?The GUI update feature makes sense for you if it''s not a time-sensitive thing. (I wasn''t sure based on the things you''ve said in recent e-mails.) Whenever there''s idle time in the GUI, it (FOX) will devote some time to the GUI update loop, in which it sends a SEL_UPDATE message to the widgets (in turn). They can use that opportunity to make sure that their settings (e.g. a label''s text, or a dial''s value) accurately reflects the current application state, e.g. viewLabel.connect(SEL_UPDATE) { viewLabel.text = modelText } There should be some examples of this in the FXRuby examples directory. Now, usually this happens very quickly because there''s a lot more idle time in a GUI application than you might realize. But if you need a value to change at fixed times (e.g. for a little onscreen clock or something) you would probably need to use a timer instead. Hope this helps, Lyle
Excellent! Thanks Lyle. I guess I have been playing my cards a bit close to my chest if I really want any good interaction on my project. The reasons for this are far less draconian than you might imagine: so many good projects get started, and for what evever reason, good or bad, get abandoned. In the end, it always makes the project owner look, shall we say, less than dilligent. So I''ll go out on a limb here. What I''m doing is a basic two-paned tabbook (ala the tabbook example). In the first pane is status information about a (potential) secure shell connection. In the second (tab) pane is a very simple dual-paned directory listing. The one on the left, the local working directory. The one on the right, the working directory at the far end of the connection. Simple drag and drop will be used to indicate which set of files will be transferred, to or from the local host. The options to start and manage a connection are provided via the application menus, and all parameters for the connection are gathered via modal dialog(s). Sensible (from a standpoint of application startup) defaults will be provided by the application. The idea is to leverage Net::SSH to provide a secure network file manager that can operate with all the conveniences and security of the SSH protocol, in combination with a simple and intuitive (well, at least commonly known and widely understood ;) UI provided by the Fox GUI Toolkit. I see the connect status pane as something that can be updated purely by this SEL_UPDATE signal; however, the timer-based update of the directory panes is still a neccesity as we have no way to get a signal from the remote host when the remote working directory is updated; polling the remote host for a new listing of the remote directory is the obvious solution (do correct me if you think there might be a better way :) Thanks again Lyle! Cheers, Twitch On 8/16/05, Lyle Johnson <lyle@knology.net> wrote:> > On Aug 15, 2005, at 9:48 PM, James Stallings II wrote: > > > Is the best way to do this to create all the top-level widgets (and > > their children) for an interface, and implement the update signals? > > Seems then I''d be able to create all the primary widgets, let the app > > change the values and send update signals back to the widgets and let > > them manage repainting themselves with the new values. > > > > Am I on the right track? if so, can anyone toss me any gems of wisdom > > before I try to get my head around the details? > > The GUI update feature makes sense for you if it''s not a time-sensitive > thing. (I wasn''t sure based on the things you''ve said in recent > e-mails.) > > Whenever there''s idle time in the GUI, it (FOX) will devote some time > to the GUI update loop, in which it sends a SEL_UPDATE message to the > widgets (in turn). They can use that opportunity to make sure that > their settings (e.g. a label''s text, or a dial''s value) accurately > reflects the current application state, e.g. > > viewLabel.connect(SEL_UPDATE) { > viewLabel.text = modelText > } > > There should be some examples of this in the FXRuby examples directory. > Now, usually this happens very quickly because there''s a lot more idle > time in a GUI application than you might realize. But if you need a > value to change at fixed times (e.g. for a little onscreen clock or > something) you would probably need to use a timer instead. > > Hope this helps, > > Lyle > >-- ==================================Woulds''t thou so blame the fragrant blos''ms wilting as never to''ve had her bloom?
Ahh, well. Of all the good reasons to abandon a project, perhaps that the application area is already well covered is one of the best. I needed to deploy this functionality a little quicker than I could deploy my own code, and upon investigation found that there are several robust solutions in place for the most commonly used OSs, most under the GPL. I''ve learned a lot from the meager distance I''ve taken it, but there''s no real reason I shouldn''t continue to learn on my next project. So, I ask you all: do you think that there is a need within the (fx)ruby community for a ssh/sftp/scp gui client specifically written in ruby? If there''s any interest, I might continue to work on it -- if you all are in agreement with me about abandoning it, I''ll blow it off and move on to the next thing. Any comments? Thanks, Twitch On 8/16/05, James Stallings II <james.stallings@gmail.com> wrote:> Excellent! Thanks Lyle. > > I guess I have been playing my cards a bit close to my chest if I > really want any good interaction on my project. > > The reasons for this are far less draconian than you might imagine: so > many good projects get started, and for what evever reason, good or > bad, get abandoned. In the end, it always makes the project owner > look, shall we say, less than dilligent. > > So I''ll go out on a limb here. > > What I''m doing is a basic two-paned tabbook (ala the tabbook example). > In the first pane is status information about a (potential) secure > shell connection. In the second (tab) pane is a very simple dual-paned > directory listing. The one on the left, the local working directory. > The one on the right, the working directory at the far end of the > connection. Simple drag and drop will be used to indicate which set of > files will be transferred, to or from the local host. > > The options to start and manage a connection are provided via the > application menus, and all parameters for the connection are gathered > via modal dialog(s). Sensible (from a standpoint of application > startup) defaults will be provided by the application. > > The idea is to leverage Net::SSH to provide a secure network file > manager that can operate with all the conveniences and security of the > SSH protocol, in combination with a simple and intuitive (well, at > least commonly known and widely understood ;) UI provided by the Fox > GUI Toolkit. > > I see the connect status pane as something that can be updated purely > by this SEL_UPDATE signal; however, the timer-based update of the > directory panes is still a neccesity as we have no way to get a signal > from the remote host when the remote working directory is updated; > polling the remote host for a new listing of the remote directory is > the obvious solution (do correct me if you think there might be a > better way :) > > Thanks again Lyle! > > Cheers, > Twitch > > > On 8/16/05, Lyle Johnson <lyle@knology.net> wrote: > > > > On Aug 15, 2005, at 9:48 PM, James Stallings II wrote: > > > > > Is the best way to do this to create all the top-level widgets (and > > > their children) for an interface, and implement the update signals? > > > Seems then I''d be able to create all the primary widgets, let the app > > > change the values and send update signals back to the widgets and let > > > them manage repainting themselves with the new values. > > > > > > Am I on the right track? if so, can anyone toss me any gems of wisdom > > > before I try to get my head around the details? > > > > The GUI update feature makes sense for you if it''s not a time-sensitive > > thing. (I wasn''t sure based on the things you''ve said in recent > > e-mails.) > > > > Whenever there''s idle time in the GUI, it (FOX) will devote some time > > to the GUI update loop, in which it sends a SEL_UPDATE message to the > > widgets (in turn). They can use that opportunity to make sure that > > their settings (e.g. a label''s text, or a dial''s value) accurately > > reflects the current application state, e.g. > > > > viewLabel.connect(SEL_UPDATE) { > > viewLabel.text = modelText > > } > > > > There should be some examples of this in the FXRuby examples directory. > > Now, usually this happens very quickly because there''s a lot more idle > > time in a GUI application than you might realize. But if you need a > > value to change at fixed times (e.g. for a little onscreen clock or > > something) you would probably need to use a timer instead. > > > > Hope this helps, > > > > Lyle > > > > > > > -- > ==================================> Woulds''t thou so blame > the fragrant blos''ms wilting > as never to''ve had her bloom? >-- ==================================Woulds''t thou so blame the fragrant blos''ms wilting as never to''ve had her bloom?
On Aug 18, 2005, at 6:53 PM, James Stallings II wrote:> Ahh, well. > > Of all the good reasons to abandon a project, perhaps that the > application area is already well covered is one of the best. I needed > to deploy this functionality a little quicker than I could deploy my > own code, and upon investigation found that there are several robust > solutions in place for the most commonly used OSs, most under the GPL.That sounds like a very pragmatic solution to me. ;)> I''ve learned a lot from the meager distance I''ve taken it, but there''s > no real reason I shouldn''t continue to learn on my next project.Sure.> So, I ask you all: do you think that there is a need within the > (fx)ruby community for a ssh/sftp/scp gui client specifically written > in ruby? If there''s any interest, I might continue to work on it -- if > you all are in agreement with me about abandoning it, I''ll blow it off > and move on to the next thing.Working on it wouldn''t be a waste of time if you learn something new while doing it. Generally speaking, though, I''m not in favor of reinventing the wheel for the sole purpose of being able to say you''ve cloned some existing, perfectly good program, in Ruby. I''d rather see that energy expended towards something innovative. You of course have to come up with that idea yourself. ;)