Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-newbies, 2016-07-14

 « Previous day | Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
11:01 meeting <meeting!~sugaroid@rev-18-85-44-69.sugarlabs.org> has joined #sugar-newbies
16:47 iamutkarshtiwari <iamutkarshtiwari!0e8bee62@gateway/web/freenode/ip.14.139.238.98> has joined #sugar-newbies
16:55 tony37 <tony37!~tony@78-0-35-173.adsl.net.t-com.hr> has joined #sugar-newbies
16:55 tony37 hello
16:58 iamutkarshtiwari hi
16:58 #startmeeting
16:58 meeting Meeting started Thu Jul 14 16:58:18 2016 UTC. The chair is iamutkarshtiwari. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:58 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
16:58 tony37 hi
16:58 iamutkarshtiwari Did you that resume activity patch?
16:58 tony37 First the bad news, I got into a bootloop again on the XO-1.75
16:59 iamutkarshtiwari I tried the same steps, but didn't happen in my case.
16:59 Did you follow the steps carefully?
16:59 tony37 When you did the compile of the schemas _ which compiles all of them - did you a get a bunch of error messages - not relating to sugar?
16:59 iamutkarshtiwari I got warnings.
16:59 But no error messages.
17:00 tony37 I have 13.2.5 (0.106) installed on the XO-1.75. I expect you have a later version on your laptop.
17:00 iamutkarshtiwari #ResumeActivityGsettings
17:00 Give me a minute. Let me check my XO version.
17:00 That could be a possiblity
17:01 tony37 You can look in the control panel - about my computer
17:01 iamutkarshtiwari Yes.
17:01 That patch got merged though! ;)
17:02 I am on 13.2.7 - (0.108)
17:02 tony37 Well done - I suspect the gsetting did the trick. We may have to do the same for the 'save as' PR
17:02 iamutkarshtiwari I think you should first update the XO to this version before testing the patch.
17:03 tony37 Agreed.
17:03 iamutkarshtiwari I have already created a PR for save as.
17:03 tony37 Have you the link?
17:03 iamutkarshtiwari But for it to get merged, we need to gain community consensus on the design.
17:04 You have already commented on that PR>
17:04 https://github.com/sugarlabs/s[…]kit-gtk3/pull/327
17:06 tony37 Looks like it hasn't changed. I thought you would provide a gif animation
17:06 iamutkarshtiwari Oh.. I will surely upload one today.
17:07 icarito hi
17:07 tony37 My model is that the alert says: Choose a name for your project [         ] save quit
17:07 Hi
17:07 iamutkarshtiwari tony37: What about overwrite?
17:07 icarito: Hi
17:07 tony37 On the resume case it could be Choose a new name for your project to save a new version [      ]  save quit
17:08 icarito by the way I tried the latest "save as" patch, it has improved
17:08 iamutkarshtiwari tony37: If the user doesn't want to provide a new name but overwrite with the same name?
17:08 icarito: Thanks :)
17:08 tony37 Then do it. This is the way save works on all the systems I am familiar with.
17:09 including Sugar
17:09 icarito i think we should consider martin dengler's comments with care. Especially the case of a young child trying to quit and being blocked
17:09 tony37 No one is blocked. They can always click on quit
17:09 iamutkarshtiwari tony37: How we handle the overwrite scenario?
17:10 icarito just a comment - the stop button (pressed a second time) should count as 'quit' action too
17:10 iamutkarshtiwari icarito: That's a nice idea.!
17:10 tony37 If the user resumed a document with a title and clicks on save, save it and delete the original jobject (document not metadata). If the user clicks on quit - quit with no save.
17:11 iamutkarshtiwari tony37: What if the user want to save the data to the 'original jboject' with the same name.?
17:11 tony37 By this time the alert is showing. So for consistency, we could offer the options save stop (the latter with a hexagon
17:11 The user doesn't know anything about jobject_ids. The user goes by the title of the object.
17:12 iamutkarshtiwari tony37: Yes. I meant the title of the object.
17:12 icarito tony37, for the same reason the system doesn't care that you have two items with the same name
17:12 so neither should the alert
17:12 tony37 If the user clicks save without changing the name - save under that name.
17:12 iamutkarshtiwari tony37: If the user wants to keep the current changes to the original object without creating a new one (duplicate) ?
17:13 tony37 I don't have a problem with duplicate titles as long as they are supplied by the user.
17:13 Once you delete the original, the only available document is the new one.
17:13 icarito all I'm saying is the prompt is not right when it says you "have an object with the same name" or so
17:13 iamutkarshtiwari tony37: So you mean that everytime a new object will be created, for sure?
17:13 icarito: Agreed.
17:14 tony37 Agreed, if the user types in A for the document name and has several others with the same name, the user's choice
17:14 A new object is created with new metadata reflecting that the user launched the activity and had it open for some period of time. This is required for statistical purposes.
17:15 Deleting the original object applies only to the document, not the metadata
17:15 icarito also this happened to me and I think it's an issue: I opened ImageMagick. Clicked Stop. Alert shows. Then I decided I went to the Frame, and to Home View. Then I came back. I clicked on "Open Image" button in ImageViewer, then it didn't work (I had forgotten about the alert). So I guess it needs to be modal, or better, be cancelled when user switches views.
17:15 iamutkarshtiwari tony37: I am getting a little confused here.
17:15 icarito tony37, I won't even go into the
17:16 'statistical purposes'
17:16 tony37 Yes it should be modal. Otherwise, we don't know what the user is doing.
17:16 icarito the notion of a modal alert is strange to me
17:16 tony37 A package was created showing graphs of laptop usage. It is considered important to show donors that the laptops they purchased are being used.
17:16 icarito (alert as in a stripe under the toolbar)
17:17 tony37, there are statistics gathering packages for sugar that don't rely in the journal
17:17 tony37 Yes, modal simply means that the alert must be responded to before anything else.
17:18 icarito forcing the user to use their journal for this is not ideal at least it should be able to be disabled
17:18 tony37 Perhaps, you need to talk this over with Walter. There is an activity to report these statistics.
17:18 I totally agree, but this was not my call.
17:18 icarito why with Walter?
17:19 tony37 He was the sponsor of this basing on a software package developed by a volunteer at OLE Nepal
17:19 ASLO is down so I can't cite the specific activity.
17:20 icarito aleksey built a statistics gathering program
17:20 tony37 Possibly but the one I am referring to is recent
17:21 icarito aleksey's solution used rrd files to efficiently store UI events
17:21 tony37 In any case, the intent is that the remotejournal will log this metadata on the school server and delete the object locally.
17:22 icarito https://wiki.sugarlabs.org/go/[…]/Usage_Statistics
17:22 tony37 In this way, the metadata object will not clutter the Journal view but will be available for review.
17:23 At least for deployments with a school server.
17:23 icarito I think that any metadata gathering for theoretical metaanalysis should be disabled by default
17:23 at least in Sugar Labs repositories
17:23 tony37 Again, not my call.
17:24 iamutkarshtiwari tony37: If the users resumes an object from Journal, does some changes to the data and saves it with the 'same name', will it overwrite the current instance or a duplicate instance needs to be created since the according to current scheme 'resuming' an instance doesn't create a new object on close.
17:24 icarito tony37, it's nobody's call, we discuss with the community
17:24 tony37 As you wish
17:25 iamutkarshtiwari: Yes. Internally, you save the new jobject with the modified document. Then you delete the document on the original jobject keeping the metadata.
17:25 From the user's perspective, you have done a save.
17:26 icarito iamutkarshtiwari, do you think it's possible to make the alert modal? I think it might not be possible.
17:26 iamutkarshtiwari tony37: So in the journal, a new object appears apart from the original one?
17:26 icarito: I'll have to overwrite the complete code all over again :D
17:27 tony37 Yes - if you look at the Journal carefully, you see that that is happening now because the creation date is updated moving the object to the first postion
17:27 position8
17:27 position*
17:28 iamutkarshtiwari tony37: Yes. But everytime the user resumes, the document gets updated but no new object is created.
17:28 tony37 You are creating a new object and cloning the metadata, AFIK
17:28 icarito iamutkarshtiwari, tony37 , since you are considering a rewrite in any case, why not consider martin's proposal to make this part of the journal?
17:29 i.e. upon closing an activity you are moved to the journal view and the title of the latest journal object is selected for editing
17:29 tony37 First, because the action is to close the activity and save the document. This happens in the activity. Second, switching to the Journal and changing a title there is already supported, but almost never used.
17:30 icarito tony37, first, what is the difference, second, yes, it's brilliant, we can reuse something we already have
17:30 tony37 How is that simpler than the current implementation. It involves both a change to activity.py and to the Journal view.
17:30 icarito yes I did not say it's easier to code I said it's simpler from a user point of view
17:31 tony37 I really have a problem understanding why this is so difficult. How is it simpler?
17:31 icarito because it's interrupting the user
17:31 the user said quit
17:31 the modal alert does not let the user quit
17:31 tony37 The user gets an alert. Types in a title and clicks on save. Done
17:31 icarito no, what if he doesn't know how to write?
17:31 we have users who don't
17:32 or even read?
17:32 it adds one layer of complexity which is too much
17:32 martin's proposal actually quits, but focuses on renaming the title of the latest journal entry
17:33 which is the action we would like to facilitate
17:33 this would relieve us of having to going thru the "Keep" debate again
17:33 i.e. maintain save actions as they currently are
17:33 you can propose changes to that independently of this feature
17:33 tony37 Either way, the user types in a title. I don't see any simplicity either in implementation or the user's perspectve
17:34 icarito tony37, modal dialogues are bad bad!
17:34 tony37 Why?
17:35 iamutkarshtiwari tony37: Modal technique was pulled down last time it was introduced for save as.
17:36 tony37 It was used to require the user to provide a description for a document - per a mommit message. This provied to be a mistake, but not relevant to the current topic.
17:37 commit*
17:38 icarito tony37, actually not
17:38 tony37, sorry but the dialog was asking for a title
17:38 it allowed for the description to be entered
17:38 but the title was focused
17:39 tony37 I lived through that - not true. The alert did nothing re the title
17:39 The title was controlled by the entry in the toolbar
17:39 icarito tony37, come on you really want to debate that? You've said you don't remember, I do
17:40 the title could be changed from this dialog!
17:40 tony37 I remember too well'
17:40 icarito tony37, lets use git
17:40 tony37 This is too difficult. We need a gsetting so that everyone can have it their way.
17:40 icarito to find it
17:40 tony37 What has git to do with this?
17:41 icarito git is a history
17:41 we don't need your memory or mine
17:41 tony37 So
17:41 icarito we can see
17:42 tony37 You mean archeology?
17:43 icarito tony37, git is really wonderful, I'm doing `git checkout v0.94.4`
17:43 tony37 Let's make this feature a gsetting option. You want it your way and I want it this way.
17:43 icarito I mean `git checkout v0.96.4`
17:44 what do you mean I don't understand what you want I'm trying to help
17:45 tony37 You tried the 'save as'. Was it burdensome to provide a title?
17:46 As you say, if you don't make the alert modal, the user can switch to another activity. I suspect when the user switches back, the alert will still be there.
17:46 icarito It malfunctioned in a couple of ways
17:47 but the rest of the buttons also still work
17:47 tony37 Great! This is what we need to know.
17:47 icarito tony37, that's exactly what my feedback was about
17:47 tony37 What was the malfunction?
17:47 iamutkarshtiwari #GetBooks
17:48 tony37 Good topic, but let's close this out first.
17:48 Information about problems with the implementation is really important
17:49 icarito tony37, utkarsh already fixed, some activities would not quit at all (chat, imageviewer)
17:49 tony37 Good!
17:50 icarito also fixed, really long delay on clicking save as
17:50 tony37 Good
17:50 icarito now pending, the label of a button is "Save as / Delete" or something
17:50 tony37 I believe there should be two labels: save and quit
17:51 icarito that label is not good also the prompt when saving as is bad - tony37 you really need to test if you want to debate it's not about your design but the patch
17:51 tony there are 4 buttons, two alerts
17:52 until you see it I don't see the point - or you had better draw what you wanted
17:52 tony37 I would love to test but so far I have not had the opportunity. I can't install patches to 0.106
17:52 icarito tony37, so don't feel attacked when I discuss the implementation that I tested
17:53 tony37 I have done that repeatedly: Choose a name for your project [       ] save quit where [    ] is a blank entry
17:53 icarito you should have a laptop with build dependencies and then maybe you can pull the tar.gz files from github
17:54 yes but then there's the case when there's already a previous journal object
17:54 tony37 I am not being attacked except by a desire not to have a modal alert or a switch to the Journal or Martin Dengler's apparent opinion that the design decisions made in 2007 are sacrosanct.
17:55 if there is a previous journal object (which, of course, has a user supplied title), the alert could be
17:55 icarito okay so you don't want a modal alert? I though you did
17:55 in that case we should catch when the user focuses away of the alert and then just cancel it
17:55 tony37 Choose a new name for this project to save a new version [Bolivar report] save quit
17:55 AFIK, alerts in Sugar are modal
17:56 icarito tony37, "the alert could be" but it's not, there's already an implementation this needs to be provided to the implementor previously to implementation
17:56 so when I discuss the implementation I'm not discussion what you think 'could be' but what actually is and how it works
17:57 tony37 It was - consider the alert on quit (your work cannot be saved ....)
17:57 icarito so my comment is just that the *current* labels on the buttons and the prompt to the user is not correct (because we allow same title objects)
17:57 tony37 I assume that the alert is modal at least in the sense that the activity will not quit and the alert will not go away until there is a response.
17:57 icarito finally to avoid non modal dialogue I propose <ESC> key cancels the quit action and so does switching apps
17:58 currently the activity *will* quit there's no way to cancel the action
17:58 "every system I've used allows to cancel the quit action"
17:58 iamutkarshtiwari tony37, icarito: I think it would be better if I can get UI mockups(approved by everyone) to get a better idea of the design so that I can re-design it properly.
17:58 tony37 No! The user chose to quit by clicking on the Stop button. It might be useful to allow escape if the user clicked on quit by mistake but that is an entirely different matter
18:00 Switching activities should have no effect on the current activity and it should be possible to return with no change of state (including alerts).
18:00 Iamutkarshtiwari - Yes
18:01 icarito tony37, well in that case there's no way about it, it needs to be modal
18:01 tony37 Yes
18:01 icarito the whole point of non-modal is that the user can do stuff without responding to the alert
18:01 if it's modal I wholeheartedly disagree with it being an alert stripe
18:02 I was already confused and ignored it
18:02 tony37 How would you like a modal dialog to be presented?
18:02 icarito tony37, as a window the way it was in 0.96 if it has to be modal
18:02 my preference would be as a journal view
18:02 we had success in peru having the first shell view on activity close be a Sugar Network feedback form
18:03 tony37 The goal is to remind the user that the document is being saved in the Journal?
18:03 icarito the goal is to facilitate to the user the ability to name journal objects!
18:03 tony37 How is it easier to type in the name on the Journal than in an entry on the alert?
18:05 Sorry, Iamutkarshtiwari - we are getting away from implementation problems again.
18:05 icarito it's not modal and it did not contradict the user (it stopped the activity)
18:05 iamutkarshtiwari icarito, tony37: I personally prefer 'current alert' technique since, it is closer to the toolbar, the 'quit' and 'stop' but are in proximity which makes naviagation easier.
18:06 tony37 So the user does not see the Journal entry - the activity simply quits
18:06 iamutkarshtiwari +1
18:06 icarito iamutkarshtiwari, however it's not modal, I'm not sure but I don't think an alert can be made modal - it's confusing because it looks like there are more options on screen than you can actually select
18:06 iamutkarshtiwari icarito: Agreed. It's not a modal.
18:07 icarito tony37, it quits and then focuses the journal entry so you can rename it if you wish
18:07 iamutkarshtiwari The screenshot patch I made was a modal popup. But not this one.
18:07 tony37 So the user's quit shows a new screen - not the Home View
18:07 icarito tony37, yes that's the proposal
18:07 tony37 iamutkarshtiwari - as I have said many times - this should work exactly as the screenshot
18:08 icarito not a new screen, we can reuse the journal
18:08 tony37 So we need three gsetting options - no change, 'save as' and a combined modification to activity.py and the Journal view?
18:10 icarito activity.py modification should be tiny just send a dbus event to the journal
18:10 tony37 While quitting?
18:11 iamutkarshtiwari How is gsettings relevant to 'save as' ?
18:12 tony37 Same as resume - allow a user or deployment to select whether the feature is enabled
18:14 icarito I guess the meeting is over I will send screenshot of the original 'Save As' dialog
18:14 iamutkarshtiwari icarito: Sure
18:14 tony37: #GetBooks
18:15 tony37 Go
18:16 icarito - thanks for joining us - I appreciate this is difficult in your time zone
18:16 iamutkarshtiwari I was using the activity today. In my opinion, addin the 'fetch books from school server' option to the the 'dropdown' list in the toolbar would be good idea.
18:17 tony37 Great!
18:17 icarito tony37, i'm glad to help
18:19 iamutkarshtiwari tony37: How should we provide the user the option to add teh schoolserver url?
18:20 tony37 I think the schoolserver urls should be data in the activity. Providing a user interface to add them would be problematical.
18:21 iamutkarshtiwari oh.. the developers need to edit the code himself?
18:23 tony37 No - different schoolservers will have different urls to access e-books. So as for the internet there will have to be several repositories.
18:24 At present, it may be easier to provide this as built-in data rather than create a user UI to enter urls.
18:24 iamutkarshtiwari But the url needs to be added to the data in the activity for which the deployer has to edit the data files?
18:26 tony37 Yes - the question is who and when? At present it may be easier to set the urls in the activity code. It is open source so a deployment can edit as needed.
18:27 iamutkarshtiwari Ok. I only need to add an extra option in the 'dropdown' to select the 'schoolserver' , add the schoolserver url to the activity data and rest the activity will do automatically?
18:29 tony37 Yes - but I believe on the internet side, GetBooks looks at several repositories (gutenberg, internet archive, etc.) So on the schoolserver, the user may want to get a book from gutenberg, pustakalaya, rachel.
18:31 iamutkarshtiwari So when the user selects the 'schoolserver' option from the 'dropdown' list,  a new list should be shown, displaying the list of offline book sources added by the deployer in the form of 'urls in acitivity data' ?
18:31 tony37 Yes
18:32 At the 30,000 foot level, all we are doing is changing the source of the books from the internet to the schoolserver.
18:33 iamutkarshtiwari Design: How to display that list of book sources?
18:33 tony37 How is that done for the internet?
18:36 iamutkarshtiwari is a*
18:36 I am quite forgetful. There is list-view in the left hand side
18:36 tony37 That should be your approach. Just change the source, not the UI as much as possible
18:37 source = book source*
18:37 iamutkarshtiwari I got it.
18:38 tony37 #remotejournal
18:38 iamutkarshtiwari Will try to show you some progress by tomorrow. I'll have to first go through code first .
18:38 tony37 I have not gotten a response from Manash recently
18:38 So you may need to undertake that project and the registration issue
18:39 iamutkarshtiwari Oh...Back up and restore feature.
18:39 tony37 I like his code - much better than my spaghetti
18:40 However, he doesn't have a schoolserver and so 'uploaded' to a local directory
18:40 iamutkarshtiwari I was little doubtful Manash would work on the project as I didn't see any progress on his github regarding Sugar lately.
18:40 tony37 Sadly, some of the enthusiasm goes out for a GSOC applicant not selected
18:41 Understandable, since an applicant needs a real summer job
18:44 iamutkarshtiwari has quit IRC
18:44 iamutkrash <iamutkrash!0e8bee62@gateway/web/freenode/ip.14.139.238.98> has joined #sugar-newbies
18:44 iamutkrash tony37:sorry
18:44 the internet got unstable here.
18:45 tony37 No problem. I am surprised that this one is so stable this evening
18:45 iamutkrash is now known as iamutkarsh
18:45 iamutkarsh Could you please redirect me to Manash's code you were talking about?
18:46 tony37 Anyway, we can duck the registration problem for the moment. There are two problems with remotejournal.
18:46 First, it uses rsync instead of sftp to handle the communication with the school server
18:46 Second, we need to figure out how to run the script
18:47 iamutkarsh tony37: I'll update you with my progress via email by tomorrow.
18:48 tony37: Agreed
18:48 tony37 OK - we are running over. See you tomorrow at 12 UTC - it is Friday.
18:48 iamutkarsh Bye
18:48 tony37 Bye
18:48 tony37 has quit IRC
18:48 iamutkarsh Sure.
18:49 iamutkarsh has quit IRC

 « Previous day | Index | Today | Next day »     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster