-
Notifications
You must be signed in to change notification settings - Fork 52
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
code clean and optimize #894
Comments
particularly for the "#if 0" case, that has at times been a habit of mine, to remove something from current use but keep it present (and visible, especially, so it's not forgotten) in case it needs to be brought back into use later. i recall using that a number of times some years ago, when doing a round of cleanups consequent to cppcheck analysis -- quite a few unused functions were kept within #if 0 blocks because i wasn't sure actual removal was a good idea. perhaps it's time to make them go away. but otherwise, yes, it seems there is always a great deal of clean-up opportunity available. there is a lot of quite old code -- old elements of the settings structure, no longer used, for example. what was previously called gnomesword started in 2000, using gtk1, and dead artifacts from almost 2 decades ago remain. |
This should be a complete no-op code wise. Nothing in this commit should change the function of the program in any way. If `git bisect` or similar ever traces a problem to this commit, then something is wrong and I didn't match start/end markers properly. This partially addresses issue crosswire#894, bullet point 1 & part of 2.
This should be a complete no-op code wise. Nothing in this commit should change the function of the program in any way. If `git bisect` or similar ever traces a problem to this commit, then something is wrong and I didn't match start/end markers properly. This partially addresses issue crosswire#894, bullet point 1 & part of 2.
This should be a complete no-op code wise. Nothing in this commit should change the function of the program in any way. If `git bisect` or similar ever traces a problem to this commit, then something is wrong and I didn't match start/end markers properly. This partially addresses issue crosswire#894, bullet point 1 & part of 2.
This should be a complete no-op code wise. Nothing in this commit should change the function of the program in any way. If `git bisect` or similar ever traces a problem to this commit, then something is wrong and I didn't match start/end markers properly. This partially addresses issue crosswire#894, bullet point 1 & part of 2.
This should be a complete no-op code wise. Nothing in this commit should change the function of the program in any way. If `git bisect` or similar ever traces a problem to this commit, then something is wrong and I didn't match start/end markers properly. This partially addresses issue crosswire#894, bullet point 1 & part of 2.
This should be a complete no-op code wise. Nothing in this commit should change the function of the program in any way. If `git bisect` or similar ever traces a problem to this commit, then something is wrong and I didn't match start/end markers properly. This partially addresses issue crosswire#894, bullet point 1 & part of 2.
This should be a complete no-op code wise. Nothing in this commit should change the function of the program in any way. If `git bisect` or similar ever traces a problem to this commit, then something is wrong and I didn't match start/end markers properly. This partially addresses issue #894, bullet point 1 & part of 2.
That is about item 3, Deprecations api migrate, like gconf to gsettings, dbus-glib to gdbus, etc. from the opening of this issue. Did it happen or did we learn that it is not wise to report several issues in a single issue? |
I opened a new issue for migrating away from dbus-glib: |
Maybe we should clean up and optimize the code if have enough time? I found those code should be cleaned up:
The text was updated successfully, but these errors were encountered: