-
Notifications
You must be signed in to change notification settings - Fork 372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create launcher widget for todo, closes #1997 #2379
Conversation
Thanks, let me know when you want a check as you mentioned "widget color scheme settings": please don't make separate colors for that. You can use the same foreground (text) and background color like at the normal editor ("" basic color scheme""). There are getters for that in AppSettings.java |
Suggestion: reuse our existing widget but replace the provider with one which supplies lines from a todo.txt file. You'll get 70% of the widget for free with good code reuse. |
app/src/main/java/net/gsantner/markor/widget/TodoWidgetRemoteViewsFactory.java
Outdated
Show resolved
Hide resolved
In these commits:
Which parts can be reused? |
Our current widget displays a list of files. Clicking on a file opens it. What you want is a list of todo text lines where clicking on a line opens the todo file at the appropriate line. We can achieve this by:
For 2 we just need to add an EXTRA_FILE with the file and EXTRA_FILE_LINE_NUMBER with the correct line number to each intent. Both can be done by creating a new factory and reusing the rest of the widget. You will need to modify the other parts of the widget to use the correct factory though. I may be missing something here, but I don't think so |
@@ -287,6 +288,11 @@ public void onPause() { | |||
_appSettings.addRecentFile(_document.getFile()); | |||
_appSettings.setDocumentPreviewState(_document.getPath(), _isPreviewVisible); | |||
_appSettings.setLastEditPosition(_document.getPath(), _hlEditor.getSelectionStart()); | |||
|
|||
if(_document.getPath().equals(_appSettings.getTodoFile().getPath())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make an appSettings function called isTodoFile or something
I would also make sure this does not slow down opening / closing the todo file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't find any other usage like this (""istodo file check"), so suggest to keep it like that. Just bloats a new method with 1 usage then.
Opening we should be fine by usual file changed detection rules, as long widget writes immedeatly when not editing anymore.
Closing not sure maybe the call can be called in a new started thread
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Fair.
Either way one should absolute paths
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roughly right or do you have something in mind which needs special attention?
guess the most important part is that the widget actually writes & reads filesystem at the right times and not resets it to older state the widget loaded in the past
@wshoy At the end the most important part is that users don't lose data..so the file management part. Years of changes of Markor told..it's very difficult to get that somewhat 99% reliable working for most users. I fear that another compound of the big calculations is then widgets and their currently loaded content. Hope it not makes too much issues. |
It is a good idea. If that happens, I think, that the ToDo functionality should be prioritized in some way (maybe making it the default file or making a separate ToDo widget). |
I assume that there is a split interest of todo vs notes/normal text editing. (so basically resembling why ToDo + QuickNote have their prominent separated existance) Just to note again - feel free to make in the PR what you have time and interest on. I can only tell what I personally think is a good way. At the end most important need is that the file handling does not spread havoc and users lose recent modifications 😄 |
Is the WIP marking still the case? |
I want to track down the issues you mentioned about virtual folders not being updated and see if there are any related issues with this approach. |
Aside from that this is done |
It's finished. |
@Override | ||
public RemoteViews getViewAt(int position) { | ||
RemoteViews views = new RemoteViews(_context.getPackageName(), R.layout.todo_widget_list_item); | ||
views.setTextViewText(R.id.todo_widget_item_text, _tasks.get(position).getDescription()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be really good to also highlight this.
Can do this pretty easily. See getSttHighlighter in MarkorDialogFactory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it needs highlighting.
String text = _tasks.get(position).getLine().replaceFirst(TodoTxtTask.PT_DATE + " ", "");
Spannable s = new SpannableString(text);
GsCallback.a1<Spannable> highlight = getSttHighlighter();
highlight.callback(s);
views.setTextViewText(R.id.todo_widget_item_text, s);
I have tried, but could not get it to work.
Using getSttHighlighter is seems to be limited to just highlighting patterns, which is good for editable text. I might be wrong.
A SpannableStringBuilder with TodoTxtTask would allow for parsing, choosing or changing elements shown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plaintext/no highlight would be enough for the first version. Especially if you anyway think about further changes
The widget is not meant to replicate whole-Markor-editor-in-a-widget.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plaintext/no highlight would be enough for the first version.
Especially if you anyway think about further changes
Do you mean, that I should merge this PR and make further changes in another?
I also plan on making another widget for regular notes which would take some time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My plan would be to get a initial version that works well enough / not makes crashes. Preferred over full featured and half stuff bare works 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well... It works well on my machine 😅
I cannot find other ways to improve it beyond what I mentioned. Maybe you might find something?
app/src/main/java/net/gsantner/markor/activity/openeditor/OpenFromShortcutOrWidgetActivity.java
Outdated
Show resolved
Hide resolved
has conflicts now unfortunatley |
Thanks you, I merged the widget! 😄 Also tried it: Seems currently limited to just displaying ToDo, and that readonly. I think editing is not a all too good idea, but selecting the file for each widget would make sense. |
Awesome to see this merged! Just curious, when will this be added to a release? |
Whenever the next release will be.
|
If I may be permitted an off-topic message, thank you so much for working on this feature! It'll be really helpful. I really appreciate the work everyone does! |
Introduces a Todo widget.
Todo: